Input Event Handling

Daniel Stone daniel at
Wed Apr 4 13:39:32 PDT 2007

On Wed, Apr 04, 2007 at 10:13:33PM +0200, Thorsten Wilms wrote:
> On Wed, Apr 04, 2007 at 10:14:24PM +0300, Daniel Stone wrote:
> > Input focus is to a particular window, so you get device -> kernel -> X
> > server -> app.
> There are cases like sliders in a windows with scrollbars. With 
> gtk+ at least, if the pointer is on the slider, mouse-wheel will 
> move the slider. But with the pointer anywhere else, the wheel 
> scrolls.
> Does this mean that input focus has to be redone on the window/ 
> application level for things like this to work?

I don't know how GTK2 does it, but in GTK1, basically everything was a
sub-window, so in this case, the input focus would be in the scrollbar

(When you see 'window', don't think 'application'.  X11 was designed for
 many embedded subwindows.)

> > > Does the kernel have a concept like input focus?
> > 
> > No, it just sends events to /dev.
> There must be some mechanism for only letting a cli app in the 
> current virtual console receive input events.

Well, the VT layer handles input events, but X will close the device
when you switch away from its VT, so it won't see those events at all.

> > This is another special case: you can grab particular _keys_.  So if you
> > want Alt-F10 to maximise in the window manager, you set a grab on F10
> > and check if Alt is also pressed.  If not, you let the event go through
> > to its original destination (i.e. the window with input focus), else you
> > intercept the event and maximise the window.
> So commonly WMs set grabs on ther shortcuts, while application just 
> wait and see what comes?


> Thank you very much for the info!

No worries.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <>

More information about the xorg mailing list