$ minicom --help Usage: minicom [OPTION]... [configuration] A terminal program for Linux and other unix-like systems.
-b, --baudrate : set baudrate (ignore the value from config) -D, --device : set device name (ignore the value from config) -s, --setup : enter setup mode -o, --noinit : do not initialize modem & lockfiles at startup -m, --metakey : use meta or alt key for commands -M, --metakey8 : use 8bit meta key for commands -l, --ansi : literal; assume screen uses non IBM-PC character set -L, --iso : don't assume screen uses ISO8859 -w, --wrap : Linewrap on -H, --displayhex : display output in hex -z, --statline : try to use terminal's status line -7, --7bit : force 7bit mode -8, --8bit : force 8bit mode -c, --color=on/off : ANSI style color usage on or off -a, --attrib=on/off : use reverse or highlight attributes on or off -t, --term=TERM : override TERM environment variable -S, --script=SCRIPT : run SCRIPT at startup -d, --dial=ENTRY : dial ENTRY from the dialing directory -p, --ptty=TTYP : connect to pseudo terminal -C, --capturefile=FILE : start capturing to FILE -F, --statlinefmt : format of status line -R, --remotecharset : character set of communication partner -v, --version : output version information and exit -h, --help : show help configuration : configuration file to use
These options can also be specified in the MINICOM environment variable. This variable is currently unset. The configuration directory for the access file and the configurations is compiled to /etc/minicom.
Report bugs to <minicom-devel@lists.alioth.debian.org>.
When an atomic commit fails then the output will be stuck in REPAINT_AWAITING_COMPLETION state. It is waiting for a vblank event that was never scheduled. If the error is EBUSY then it can be expected to be a transient error. So propagate the error and schedule a new repaint in the core compositor.
This is necessary because there are some circumstances when the commit can fail unexpectedly: - With 'state_invalid == true' one commit will disable all planes. If another commit for a different output is triggered immediately afterwards, then this commit can temporarily fail with EBUSY because it tries to use the same planes. - At least with i915, if one commit enables an output then a second commit for a different output immediately afterwards can temporarily fail with EBUSY. This is probably caused by some hardware interdependency. Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
libweston/backend-drm/drm.c의 drm_repaint_flush()와
libweston/compositor.c의 output_repaint_timer_hander() 쪽에 수정이 가해진다.
WL_EXPORT void weston_output_disable_planes_incr(struct weston_output *output) { output->disable_planes++; /* * If disable_planes changes from 0 to non-zero, it means some type of * recording of content has started, and therefore protection level of * the protected surfaces must be updated to avoid the recording of * the protected content. */ if (output->disable_planes == 1) weston_schedule_surface_protection_update(output->compositor); }
struct content_protection은 누가 만드나 하면서 따라가보니
weston_compositor_enable_content_protection() 함수에서 만들어 주고 해당 함수는
//git\libweston\content-protection.c WL_EXPORT int weston_compositor_enable_content_protection(struct weston_compositor *compositor) { struct content_protection *cp;
C Specification void glReadPixels( GLint x, GLint y, GLsizei width, GLsizei height, GLenum format, GLenum type, GLvoid * data); Parameters x, y Specify the window coordinates of the first pixel that is read from the frame buffer. This location is the lower left corner of a rectangular block of pixels.
width, height Specify the dimensions of the pixel rectangle. width and height of one correspond to a single pixel.
24/03/2021 11:09:19 Pixel format for client 192.168.0.6: 24/03/2021 11:09:19 87 bpp, depth 5, little endian 24/03/2021 11:09:19 true colour: max r 47360 g 20997 b 2, shift r 179 g 0 b 77 24/03/2021 11:09:19 rfbSetTranslateFunction: client bits per pixel not 8, 16 or 32 24/03/2021 11:09:19 Client 192.168.0.6 gone
/* This call creates a mask and then a cursor: */ /* rfbScreen->defaultCursor = rfbMakeXCursor(exampleCursorWidth,exampleCursorHeight,exampleCursor,0); */
MakeRichCursor(rfbScreen);
/* initialize the server */ rfbInitServer(rfbScreen);
#ifndef BACKGROUND_LOOP_TEST #ifdef USE_OWN_LOOP { int i; for(i=0;rfbIsActive(rfbScreen);i++) { fprintf(stderr,"%d\r",i); rfbProcessEvents(rfbScreen,100000); } } #else /* this is the blocking event loop, i.e. it never returns */ /* 40000 are the microseconds to wait on select(), i.e. 0.04 seconds */ rfbRunEventLoop(rfbScreen,40000,FALSE); #endif /* OWN LOOP */ #else #if !defined(LIBVNCSERVER_HAVE_LIBPTHREAD) && !defined(LIBVNCSERVER_HAVE_WIN32THREADS) #error "I need pthreads or win32 threads for that." #endif /* catch Ctrl-C to set a flag for the main thread */ signal(SIGINT, intHandler); /* this is the non-blocking event loop; a background thread is started */ rfbRunEventLoop(rfbScreen,-1,TRUE); fprintf(stderr, "Running background loop...\n"); /* now we could do some cool things like rendering in idle time */ while (maintain_connection) { sleep(5); /* render(); */ } fprintf(stderr, "\nShutting down...\n"); rfbShutdownServer(rfbScreen, TRUE); #endif /* BACKGROUND_LOOP */
revind / revind.so / run / websockify 는 websockify 에서 나온거
libvncserver 와 noVNC와 websockify 의 조합으로 어찌 되긴 하는데..
~/libvncserver/webclients $ ls -al total 64 drwxr-xr-x 4 pi pi 4096 Aug 12 11:44 . drwxr-xr-x 16 pi pi 4096 Aug 12 11:03 .. -rwxr-xr-x 1 pi pi 25372 Aug 12 11:02 example -rw-r--r-- 1 pi pi 1601 Aug 12 10:32 index.vnc drwxr-xr-x 10 pi pi 4096 Aug 12 11:00 novnc -rwxr-xr-x 1 pi pi 424 Aug 12 11:39 rebind -rwxr-xr-x 1 pi pi 7508 Aug 12 11:39 rebind.so -rwxr-xr-x 1 pi pi 78 Aug 12 11:39 run drwxr-xr-x 3 pi pi 4096 Aug 12 11:28 websockify
인자는 아래와 같이 하고 실행!
$ ./run 5900 -- ./example
웹 브라우저에서 http://ip:5800 으로 접속하면 아래와 같이 뜨고
별다른 설정을 하지 않았다면 wss(websocket secure)를 안될테니 위에 "Click here to connect using noVNC"를 누른다.
약간의 시간을 기다리면(libvncserver의 웹 서버가 느린지 파일 전송이 좀 느리다)
아래와 같이 쨘~
+
한번 되더니 websockify 없이도 되네.. 머지?
+
runInBackground 의 값을 TRUE 로 해주면 웹 서버가 작동을 안한다 -_-
어떻게 해야 할까..
void rfbRunEventLoop ( rfbScreenInfoPtr screenInfo, long usec, rfbBool runInBackground )
static THREAD_ROUTINE_RETURN_TYPE listenerRun(void *data) { rfbScreenInfoPtr screen=(rfbScreenInfoPtr)data; int client_fd; struct sockaddr_storage peer; rfbClientPtr cl = NULL; socklen_t len; fd_set listen_fds; /* temp file descriptor list for select() */
/* Only checking socket state here and not using rfbIsActive() because: When rfbShutdownServer() is called by the client, it runs in the client-to-server thread's context, resulting in itself calling its own the pthread_join(), returning immediately, leaving the client-to-server thread to actually terminate _after_ the listener thread is terminated, leaving the client list still populated. */ /* TODO: HTTP is not handled */ }
