How is how inputs gets routed to the right window out of scope for an article that wants to describe input end to end? The fact that input events get carefully routed to the right thing is both important and a potential source of bugs if not implemented correctly.
> How is how inputs gets routed to the right window
It is covered for both X11 and Wayland. I just don't get into the particular decisions and details of how each WM/DE picks what they deem the current focused window, since it varies widely and it's more part of window management than of input management (I've written a WM and it's a bit messy). An article on WM/Compositor development would be more appropriate for that, I have a few already on my blog.
>Obviously, each have their own internal representation and ways of managing the information they get from libinput, XKB, and others, but this is outside the scope of this article
From what I can tell this is the explaination. It says that they manage input. If this is good enough why not simplify what the kernel does by saying Linux has its own way of handling inputs from keyboard and that is out of scope. It just seems arbitrary what handling of input is and isn't in scope.
That’s the domain of a window manager. It’s touched on in the article, but going into detail about the edge cases would require detours into user space window manager choices and even preference settings.
I'm not even talking about edge cases. It doesn't even give a high level. It just treats wayland and x as big black boxes and does not explain what happens inside of them.
I'm was expecting a full end to end analysis of how inputs travels through the system. A proper analysis shouldn't just examine both ends of the system, but follow what happens during each step of the process.
How is how inputs gets routed to the right window out of scope for an article that wants to describe input end to end? The fact that input events get carefully routed to the right thing is both important and a potential source of bugs if not implemented correctly.
> How is how inputs gets routed to the right window
It is covered for both X11 and Wayland. I just don't get into the particular decisions and details of how each WM/DE picks what they deem the current focused window, since it varies widely and it's more part of window management than of input management (I've written a WM and it's a bit messy). An article on WM/Compositor development would be more appropriate for that, I have a few already on my blog.
Someone else can explain, how me pressing "a" gets to light some LEDs on my screen, and what happens in the output part of the data flow.
It's not covered.
>Obviously, each have their own internal representation and ways of managing the information they get from libinput, XKB, and others, but this is outside the scope of this article
From what I can tell this is the explaination. It says that they manage input. If this is good enough why not simplify what the kernel does by saying Linux has its own way of handling inputs from keyboard and that is out of scope. It just seems arbitrary what handling of input is and isn't in scope.
That’s the domain of a window manager. It’s touched on in the article, but going into detail about the edge cases would require detours into user space window manager choices and even preference settings.
I'm not even talking about edge cases. It doesn't even give a high level. It just treats wayland and x as big black boxes and does not explain what happens inside of them.
It sounds like you’re looking for an article on window managers, which would be a separate topic.
I'm was expecting a full end to end analysis of how inputs travels through the system. A proper analysis shouldn't just examine both ends of the system, but follow what happens during each step of the process.
Are there any good resources to learn how they work?
Very impressive, nice work!