| |||||||||||||
LPC: Life after XLPC: Life after XPosted Nov 7, 2010 19:20 UTC (Sun) by iabervon (subscriber, #722)Parent article: LPC: Life after X
Since this comes up during the "Lessons from Unix" series, it seems to me like the obvious right solution, now that we've got the hardware for it, is to say that applications open a pseudo-terminal device, which provides input events and has a frame buffer which supports various elaborate operations. But these aren't hardware devices any more than pts/1 is; the input events are only those directed to the application that got the pseudo-terminal, and the frame buffer is only the application's window, and the kernel is providing an abstraction layer and hiding what is on the other side. It may be that there is a userspace program which is compositing the windows onto the hardware frame buffer; then again, the windows might be hardware texture maps, and a userspace program has simply arranged the hardware's scene graph to have these textures get rendered. Or maybe the framebuffer device is proxying everything over a network connection.
But I think the important magic is really having OpenGL as system calls on a file descriptor for a graphical pts device; even though OpenGL in the kernel is a terrible idea, OpenGL over a channel that the kernel is responsible for is a great idea, and even better if the "device" side of the channel can tell the hardware driver to snoop and handle stuff that the hardware supports directly.
(Log in to post comments)
LPC: Life after X Posted Nov 7, 2010 21:42 UTC (Sun) by zander76 (guest, #6889) [Link]
Hey,
It seems like this solution is a little to close to the metal. I would be more inclined to deal with the actual event and not the keystroke. The data would be my concern and leave control of mouse/keyboards in the hands of the client itself. Perhaps I am missing a use case that would require that level.
Even in real time gaming I have graphics cached on the client and I only send information like position and direction type information to the server. The individual keystrokes and mouse events are handled completely on the client side. The results of their events are sent along the wire.
Ben
LPC: Life after X Posted Nov 7, 2010 23:22 UTC (Sun) by iabervon (subscriber, #722) [Link]
I think you're misunderstanding my proposed architecture; there's a daemon on the computer with the keyboard that decides which application should see a key press event when the user presses a key on that keyboard. That daemon may also provide keystroke events when the user interacts with an on-screen picture of a keyboard and omit keystrokes that have been configured to control the mouse pointer. For some touchpads, the daemon would map between what the hardware outputs (two fingers moving in a particular way) and what that gesture means (scroll up), so the touchpad behavior is consistent across applications.
If the application is remote, the devices it has opened on the machine it is running on simply proxy the devices that an application on the machine with the hardware would have opened; all of the "what does this particular output from this particular hardware" is dealt with on the machine with that hardware.
I think, in fact, that we agree on what should be done where, but the terms "client" and "server" are somewhat unclear in the context of online gaming in X; the "client" is the application, but there are things called "servers" both closer to the user and further away from the user, and all three programs depend on operating system services.
LPC: Life after X Posted Nov 7, 2010 22:00 UTC (Sun) by dtlin (✭ supporter ✭, #36537) [Link] Speaking of "Lessons from Unix" Plan 9 provided /dev/cons, /dev/mouse, and /dev/draw devices for keyboard input, mouse input, and screen RPCs. The 8½ (later rio) window manager would rebind these devices for each process opening a new window (plus a few others for window management) and would act as a multiplexer. Network transparency becomes just mounting a filesystem remotely. Sounds not too far off of what you're suggesting here.
|
|||||||||||||