Re: [DNG] Why X does keyboard and mouse.
Quoting Hendrik Boom (hend...@topoi.pooq.com): > My ancient experience with X was working on the team developing UIM/X in > the days before Linux. I spent some time reading a manual caalled > something like IC (maybe ICCCM?) about communications between these > various network components, though I never had to do any coding directly > with that communication. ICCCM (Inter-Client Communication Conventions Manual). https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html X deliberately specifies "mechanism, not policy" for how windows interact. As such, an additional specification beyond the X protocol itself was needed for client interoperation. The ICCCM specifies cut and paste buffers, window manager interaction, session management, how to manipulate shared resources and how to manage device colours. These low-level functions are generally implemented within widget toolkits or desktop environments. This isolates application programmers from working directly with the ICCCM itself, as this functionality is delegated to the implementing toolkit. The ICCCM is notorious for being ambiguous and difficult to correctly implement. Furthermore, some parts are obsolete or no longer practical to implement. Efforts to update and clarify the ICCCM for current needs have resulted in the Extended Window Manager Hints (EWMH), which has gained fairly broad acceptance and continues to be extended as the need arises. https://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual ICCCM came in for some memorable if passing derision in The UNIX-Hater's Handbook. http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html -- Cheers, "The plural of regex is regrets." Rick Moen -- old coder gag, seen on Reddit r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Fri, Jan 01, 2021 at 05:02:32PM -0800, Ian Zimmerman wrote: > On 2021-01-01 19:07, Hendrik Boom wrote: > > > It is that intermediate window manager that was responsible for border > > sized and so forth. It couldn't draw the borders -- it wasn't attached > > to a screen. It just told the server what to draw. > > Yes, of course. That is what I meant. Nonetheless, the _server_ (ie. the > Xorg daemon) is the ultimate source of truth on the locations on > windows. The WM asks Xorg for that information. Make sense. Things are not as clear-cut these days as to who dies what whan they're all on the same computer. > > I contributed code to openbox - be careful who you're talking to :-P Nice. My ancient experience with X was working on the team developing UIM/X in the days before Linux. I spent some time reading a manual caalled something like IC (maybe ICCCM?) about communications between these various network components, though I never had to do any coding directly with that communication. I remember once working with a really charming little X terminal. I no longer know what model it was. Hard to find such a thing nowadays, but I use my laptop as one when I want to run elsewhere. Software really isn't kind to using it via networked ssh -X these days. Running Chromium on a remote machine is terrible when it does animated scrolling. It transmits all those successive bitmaps one by one and doesn't look animated at all, just slow. -- hendrik > > -- > Ian > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On 2021-01-01 19:07, Hendrik Boom wrote: > It is that intermediate window manager that was responsible for border > sized and so forth. It couldn't draw the borders -- it wasn't attached > to a screen. It just told the server what to draw. Yes, of course. That is what I meant. Nonetheless, the _server_ (ie. the Xorg daemon) is the ultimate source of truth on the locations on windows. The WM asks Xorg for that information. I contributed code to openbox - be careful who you're talking to :-P -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Fri, Jan 01, 2021 at 12:22:50PM -0800, Ian Zimmerman wrote: > On 2021-01-01 15:05, Hendrik Boom wrote: > > > This kind of remapping, and others, such as managing window borders, > > is done by the window manager in X. The window manager is a separate > > process, doesn't need to be present, and can even run on a separate > > machine from the client and/or server. > > I am quite sure you are wrong here. The window manager _draws_ the > borders, but the server definitely knows where they are. > > And as for keyboard sending pointer events: > > https://en.wikipedia.org/wiki/Mouse_keys#Enabling > > (I use the setxkbmap method.) The terminology with X is a bit reversed from the usual client/server notation. The X server is tha machine with the screen, keyboard, and mouse. The X client is the machine that's running your application. It asks the server to display your stuff for you. I date back to the old days, when the window manager could run on yet another machine and intercept messages going between the client and server and changes them as it considerse appropriate. It is that intermediate window manager that was responsible for border sized and so forth. It couldn't draw the borders -- it wasn't attached to a screen. It just told the server what to draw. The introduction of direct rendering has eroded these distinctions somewhat. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On 2021-01-01 15:05, Hendrik Boom wrote: > This kind of remapping, and others, such as managing window borders, > is done by the window manager in X. The window manager is a separate > process, doesn't need to be present, and can even run on a separate > machine from the client and/or server. I am quite sure you are wrong here. The window manager _draws_ the borders, but the server definitely knows where they are. And as for keyboard sending pointer events: https://en.wikipedia.org/wiki/Mouse_keys#Enabling (I use the setxkbmap method.) -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Fri, Jan 01, 2021 at 10:52:52AM -0800, Ian Zimmerman wrote: > On 2020-12-31 12:21, Hendrik Boom wrote: > > > On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > > > > > It didn't have to be this way. In 2020, better alternatives could have > > > been made. If I were the project manager, the first thing I'd do is > > > uncouple keyboard, mouse and video from each other. Why X has anything > > > to do with keyboard or mouse is beyond me. > > > Perhaps because X was originally a means of having a graphical user > > interface to multiple machines over a network. Which usualy involves > > a screen, keyboard, and mouse. > > Also, many people prefer to use the keyboard to generate many, most, or > even all the pointer events. While this remapping or emulation (whatever > you want to call it) can in theory be done on the application or toolkit > level [1] that means duplication and some applications will inevitably > left behind. This kind of remapping, and others, such as managing window borders, is done by the window manager in X. The window manager is a separate process, doesn't need to be present, and can even run on a separate machine from the client and/or server. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Fri, Jan 01, 2021 at 04:38:05PM +, Simon Hobson wrote: > Hendrik Boom wrote: > > It didn't have to be this way. In 2020, better alternatives could > have been made. If I were the project manager, the first thing I'd > do is uncouple keyboard, mouse and video from each other. Why X has > anything to do with keyboard or mouse is beyond me. > >>> > >>> Perhaps because X was originally a means of having a graphical user > >>> interface to multiple machines over a network. Which usualy involves > >>> a screen, keyboard, and mouse. > >>> > >>> Each X window could be talking to a different computer. It mattered > >>> which computer your keystrokes went to. > >> > >> Yes, but that doesn't preclude three or more separate pieces of > >> software: One for the screen, one for the keyboard, and one for the > >> mouse. There can be others as input devices are added. There could even > >> be a struct that passes a pointer to each of those three (or more). > > > > The X server would still have to take the keystrokes, see which window was > > active and sent those keystrokes to the remote machine using that window. > > That > > connects them together. > > ... > > > But when the X inventors did this, they left out audio. I can connect to a > > remote host, run a media player, and never hear the sound, because it's > > playing > > on the remote host. > > In some ways that's an argument for doing some form of multiple streams - and > multiplex them down one transport. That way, you implement the stream types > you know about now, and when new ones come along (e.g. people now want audio > rather than just a beep) then it can be easily added as an additional stream > type. I think that's what X does now -- it multiplexes several event streams. But not, as far as I know, audio. Though I have heard of someone trying that a while ago. > Intelligent multiplexing should be able to retain the sequence of > (e.g. key presses and mouse clicks), though I guess there's always the > chance that processes could get scheduled in such a way that very > closely spaced events might get re-ordered. Such an example could be > if you hit a key and click the mouse together - but given the > processing abilities of modern hardware, I think it would need to be > "together" (from human response times PoV) for it to be a risk. Indeed. At the lowest level, there are probably different device drivers for mouse, keyboard, tracker ball, game console, and the like. > > But really it's a moot discussion. It didn't happen, and it's not likely to > given the vested interests in pushing their own ideas these days. I've heard that Wayland was to be able to operate over X. Whether that actually works, or is to be dropped, I have no idea. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On 2020-12-31 12:21, Hendrik Boom wrote: > On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > > It didn't have to be this way. In 2020, better alternatives could have > > been made. If I were the project manager, the first thing I'd do is > > uncouple keyboard, mouse and video from each other. Why X has anything > > to do with keyboard or mouse is beyond me. > Perhaps because X was originally a means of having a graphical user > interface to multiple machines over a network. Which usualy involves > a screen, keyboard, and mouse. Also, many people prefer to use the keyboard to generate many, most, or even all the pointer events. While this remapping or emulation (whatever you want to call it) can in theory be done on the application or toolkit level [1] that means duplication and some applications will inevitably left behind. I'm surprised nobody else brought this up here :-P So I think the idea of an integrated _input_ management layer is still sound, at least. Something also needs to keep track in which window pointer events occur and which window has focus for keyboard events. Sure, that can be decoupled from the low-level _generation_ of events, but aren't we already well along that path with Xorg and libinput? I agree that X11 sucks but I think the reasons are more in the low level protocol design than in the overall partition of responsibilities. [1]: which is the approach of Wayland, if I understand right. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
Hendrik Boom wrote: It didn't have to be this way. In 2020, better alternatives could have been made. If I were the project manager, the first thing I'd do is uncouple keyboard, mouse and video from each other. Why X has anything to do with keyboard or mouse is beyond me. >>> >>> Perhaps because X was originally a means of having a graphical user >>> interface to multiple machines over a network. Which usualy involves >>> a screen, keyboard, and mouse. >>> >>> Each X window could be talking to a different computer. It mattered >>> which computer your keystrokes went to. >> >> Yes, but that doesn't preclude three or more separate pieces of >> software: One for the screen, one for the keyboard, and one for the >> mouse. There can be others as input devices are added. There could even >> be a struct that passes a pointer to each of those three (or more). > > The X server would still have to take the keystrokes, see which window was > active and sent those keystrokes to the remote machine using that window. > That > connects them together. ... > But when the X inventors did this, they left out audio. I can connect to a > remote host, run a media player, and never hear the sound, because it's > playing > on the remote host. In some ways that's an argument for doing some form of multiple streams - and multiplex them down one transport. That way, you implement the stream types you know about now, and when new ones come along (e.g. people now want audio rather than just a beep) then it can be easily added as an additional stream type. Intelligent multiplexing should be able to retain the sequence of (e.g. key presses and mouse clicks), though I guess there's always the chance that processes could get scheduled in such a way that very closely spaced events might get re-ordered. Such an example could be if you hit a key and click the mouse together - but given the processing abilities of modern hardware, I think it would need to be "together" (from human response times PoV) for it to be a risk. But really it's a moot discussion. It didn't happen, and it's not likely to given the vested interests in pushing their own ideas these days. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Thu, Dec 31, 2020 at 12:21:47PM -0500, Hendrik Boom wrote: > On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > > > > It didn't have to be this way. In 2020, better alternatives could have > > been made. If I were the project manager, the first thing I'd do is > > uncouple keyboard, mouse and video from each other. Why X has anything > > to do with keyboard or mouse is beyond me. > > Perhaps because X was originally a means of having a graphical user interface > to multiple machines over a network. Which usualy involves a screen, > keyboard, > and mouse. > > Each X window could be talking to a different computer. It mattered which > computer your keystrokes went to. And I normally run with several windows on one screen, connected via X to differenf computers. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Thu, Dec 31, 2020 at 12:39:21PM -0500, Steve Litt wrote: > On Thu, 31 Dec 2020 12:21:47 -0500 > Hendrik Boom wrote: > > > On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > > > > > > > It didn't have to be this way. In 2020, better alternatives could > > > have been made. If I were the project manager, the first thing I'd > > > do is uncouple keyboard, mouse and video from each other. Why X has > > > anything to do with keyboard or mouse is beyond me. > > > > Perhaps because X was originally a means of having a graphical user > > interface to multiple machines over a network. Which usualy involves > > a screen, keyboard, and mouse. > > > > Each X window could be talking to a different computer. It mattered > > which computer your keystrokes went to. > > Yes, but that doesn't preclude three or more separate pieces of > software: One for the screen, one for the keyboard, and one for the > mouse. There can be others as input devices are added. There could even > be a struct that passes a pointer to each of those three (or more). The X server would still have to take the keystrokes, see which window was active and sent those keystrokes to the remote machine using that window. That connects them together. Not clear what would be the advantage in using separate channels except maybe achieving confusion in the order of clicks and keybard events. When the remote machine gets these clicks and events, it can do what it pleases with them. There was even a provision for having a window manager (which could run on a third machine) and intervene in the conversations. But when the X inventors did this, they left out audio. I can connect to a remote host, run a media player, and never hear the sound, because it's playing on the remote host. -- hendrik > > SteveT > > Steve Litt > Autumn 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
On Thu, 31 Dec 2020 12:21:47 -0500 Hendrik Boom wrote: > On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > > > > It didn't have to be this way. In 2020, better alternatives could > > have been made. If I were the project manager, the first thing I'd > > do is uncouple keyboard, mouse and video from each other. Why X has > > anything to do with keyboard or mouse is beyond me. > > Perhaps because X was originally a means of having a graphical user > interface to multiple machines over a network. Which usualy involves > a screen, keyboard, and mouse. > > Each X window could be talking to a different computer. It mattered > which computer your keystrokes went to. Yes, but that doesn't preclude three or more separate pieces of software: One for the screen, one for the keyboard, and one for the mouse. There can be others as input devices are added. There could even be a struct that passes a pointer to each of those three (or more). SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Why X does keyboard and mouse.
On Thu, Dec 31, 2020 at 11:53:51AM -0500, Steve Litt wrote: > > > It didn't have to be this way. In 2020, better alternatives could have > been made. If I were the project manager, the first thing I'd do is > uncouple keyboard, mouse and video from each other. Why X has anything > to do with keyboard or mouse is beyond me. Perhaps because X was originally a means of having a graphical user interface to multiple machines over a network. Which usualy involves a screen, keyboard, and mouse. Each X window could be talking to a different computer. It mattered which computer your keystrokes went to. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
