xf86PostKeyEvent and xf86PostKeyboardEvent

[Andrew Zabolotny-3]

Hello!

I'm working here on a tablet driver for my wacom tablet, and while
doing that I've encountered a problem that I think is a bug in X11
core. Can someone enlighten me if I'm correct in my assumptions:

a) xf86PostKeyEvent won't work for devices with 0 valuators as seen
from xf86XInput.c - if num_valuators is 0, the loop never executes, and
no events are posted. This is actually a bug from my point of view,
since the analogous function xf86PostButtonEvent() checks for the case
when number of valuators is 0 and posts a proper event in any case.

b) xf86PostKeyboardEvent won't work for non-core devices, since it
doesn't fill xev->deviceid field, thus xf86eqProcessInputEvents () will
barf "LookupDeviceIntRec id=0x%x not found". I'm not sure why it
doesn't barf on core key events for the same reason, but it's obvious it
doesn't -- otherwise the regular keyboard driver wouldn't work. This
seems a bug as well, as seen from xf86PostKeyEvent there are two
missing lines in xf86PostKeyboardEvent:

xf86Info.lastEventTime = xev->time = GetTimeInMillis();
xev->deviceid = device->id;

besides, xE[2] could be just xE.

So it turns out that there is no way to generate non-core key events. I
would like to generate key events for tablet pad buttons, but since the
pad subdevice sometimes (e.g. on my tablet) has no valuators, the only
quirk that comes to my mind is to pretend that it has at least one
valuator, which would result in bogus events being emited.

BTW all said above refers to xorg 6.8.2 sources. If it is already fixed
in later versions, I'm sorry.

--
Greetings,
   Andrew
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Zephaniah E. Hull]

On Sun, Mar 19, 2006 at 03:57:47PM +0300, Andrew Zabolotny wrote:

> Hello!
>
> I'm working here on a tablet driver for my wacom tablet, and while
> doing that I've encountered a problem that I think is a bug in X11
> core. Can someone enlighten me if I'm correct in my assumptions:
>
> a) xf86PostKeyEvent won't work for devices with 0 valuators as seen
> from xf86XInput.c - if num_valuators is 0, the loop never executes, and
> no events are posted. This is actually a bug from my point of view,
> since the analogous function xf86PostButtonEvent() checks for the case
> when number of valuators is 0 and posts a proper event in any case.
>
> b) xf86PostKeyboardEvent won't work for non-core devices, since it
> doesn't fill xev->deviceid field, thus xf86eqProcessInputEvents () will
> barf "LookupDeviceIntRec id=0x%x not found". I'm not sure why it
> doesn't barf on core key events for the same reason, but it's obvious it
> doesn't -- otherwise the regular keyboard driver wouldn't work. This
> seems a bug as well, as seen from xf86PostKeyEvent there are two
> missing lines in xf86PostKeyboardEvent:

These two functions (along with several others) are going to be reworked
somewhat, most likely after 7.1 but hopefully before 7.2, at which point
all of the input drivers will need at least some small changes, and in
some cases some larger changes.

Tablet drivers that support multiple tools will require some much
heavier changes, but the specifics have not been put into concrete yet.


By the way, what's special about the wacom tablet in question that it
requires a new driver?  What interface does it use and such?


Zephaniah E. Hull.

--
          1024D/E65A7801 Zephaniah E. Hull <warp@...>
           92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
            CCs of replies from mailing lists are requested.

   "<green>From</yellow>"
   "Wow. The green word From is no longer yellow. That's deep, man."
 -- Marcus Meissner & Lars Balker Rasmussen in the Scary Devil Monastery


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Andrew Zabolotny-3]

On Mon, 20 Mar 2006 02:06:44 -0500
"Zephaniah E. Hull" <warp@...> wrote:

> These two functions (along with several others) are going to be
> reworked somewhat, most likely after 7.1 but hopefully before 7.2, at
> which point all of the input drivers will need at least some small
> changes, and in some cases some larger changes.
>
> Tablet drivers that support multiple tools will require some much
> heavier changes, but the specifics have not been put into concrete
> yet.
Aha, that's great. Xinput certainly lacks a code review session.

By the way, are there any plans on doing something with input device
axis numbers? For now gtk just always supposes that axis 0 is x, axis 1
is y, axis 2 is pressure, axis 3 is xtilt, axis 4 is ytilt, axis 5 is
wheel.... this looks like a kind of hack. Some string 'role' associated
with every axis or something like this would work... For example, on the
'pad' tablet subdevice I don't have x/y/pressure/xtilt/ytilt but for
example I have a wheel... but I can't define axis 5 without axes 0-4,
so gtk applications are fooled into thinking that 'pad' has valid
x/y/pressure/tilt values.

> By the way, what's special about the wacom tablet in question that it
> requires a new driver?  What interface does it use and such?
Well, first it's a bluetooth tablet so I had to write the kernel driver
from scratch (all other wacom tablets are either serial or USB). And
second, like I said above, tablet buttons are unusable without using
special programs that translate extended button events into X11
events... I'm implementing this ability directly in the driver, e.g.
you may assign any x11 mouse/keyboard event to any tablet button
directly, and also you may choose whenever to generate a core event or
a 'extended input' event. The codebase for the driver is from the
wacom-linux project...

Why I'm concerned with buttons so much is that I've implemented in my
driver 17 'hot spots' along the edges of the active tablet area (but
outside of it) that work like buttons when you touch them with the
stylus/eraser. I discovered that tablet is sensible to one coordinate
along the edges of the active area, so I thought why not use it for
'pseudo-buttons' that would allow you to switch GIMP tools and do other
useful stuff...

--
Greetings,
   Andrew
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Daniel Stone-3]

On Tue, Mar 21, 2006 at 12:52:15AM +0300, Andrew Zabolotny wrote:

> On Mon, 20 Mar 2006 02:06:44 -0500
> "Zephaniah E. Hull" <warp@...> wrote:
> > These two functions (along with several others) are going to be
> > reworked somewhat, most likely after 7.1 but hopefully before 7.2, at
> > which point all of the input drivers will need at least some small
> > changes, and in some cases some larger changes.
> >
> > Tablet drivers that support multiple tools will require some much
> > heavier changes, but the specifics have not been put into concrete
> > yet.
>
> Aha, that's great. Xinput certainly lacks a code review session.

Zepheniah and I have been working on it.

> By the way, are there any plans on doing something with input device
> axis numbers? For now gtk just always supposes that axis 0 is x, axis 1
> is y, axis 2 is pressure, axis 3 is xtilt, axis 4 is ytilt, axis 5 is
> wheel.... this looks like a kind of hack. Some string 'role' associated
> with every axis or something like this would work... For example, on the
> 'pad' tablet subdevice I don't have x/y/pressure/xtilt/ytilt but for
> example I have a wheel... but I can't define axis 5 without axes 0-4,
> so gtk applications are fooled into thinking that 'pad' has valid
> x/y/pressure/tilt values.

My current thoughts are to have an addendum to the spec that defines
behaviours for certain device classes.  e.g. DEVICE_TOUCHSCREEN provides
x data on axis 0, y data on axis 1, pressure data on axis 2.

> > By the way, what's special about the wacom tablet in question that it
> > requires a new driver?  What interface does it use and such?
>
> Well, first it's a bluetooth tablet so I had to write the kernel driver
> from scratch (all other wacom tablets are either serial or USB). And
> second, like I said above, tablet buttons are unusable without using
> special programs that translate extended button events into X11
> events... I'm implementing this ability directly in the driver, e.g.
> you may assign any x11 mouse/keyboard event to any tablet button
> directly, and also you may choose whenever to generate a core event or
> a 'extended input' event. The codebase for the driver is from the
> wacom-linux project...

The idea is that the current CorePointer/SendCoreEvents idiocy should go
away, and instead you have virtual core devices that merely aggregate
events from other devices (you can move devices in and out of core at
runtime).

> Why I'm concerned with buttons so much is that I've implemented in my
> driver 17 'hot spots' along the edges of the active tablet area (but
> outside of it) that work like buttons when you touch them with the
> stylus/eraser. I discovered that tablet is sensible to one coordinate
> along the edges of the active area, so I thought why not use it for
> 'pseudo-buttons' that would allow you to switch GIMP tools and do other
> useful stuff...

That would indeed be useful.


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Andrew Zabolotny-3]

On Tue, 21 Mar 2006 12:06:08 +0200
Daniel Stone <daniel@...> wrote:

> > work... For example, on the 'pad' tablet subdevice I don't have x/y/
> > pressure/xtilt/ytilt but for example I have a wheel... but I can't
> > define axis 5 without axes 0-4, so gtk applications are fooled into
> > thinking that 'pad' has valid x/y/pressure/tilt values.
> My current thoughts are to have an addendum to the spec that defines
> behaviours for certain device classes.  e.g. DEVICE_TOUCHSCREEN
> provides x data on axis 0, y data on axis 1, pressure data on axis 2.
Hmm, that would help as well, but what of the existing XI_XXX constants
should I use for tablet's pad, for example? The 'Pad' subdevice may
have lots of buttons, and also it may have one or two (or may be more?)
fingerstrips that can be used for scrolling and such. XI_KEYBOARD?
Keyboard doesn't have fingerstrips. XI_BUTTONBOX? What's a buttonbox?
XI_NINE_KNOB? Pretty descriptive :)

> The idea is that the current CorePointer/SendCoreEvents idiocy should
> go away, and instead you have virtual core devices that merely
> aggregate events from other devices (you can move devices in and out
> of core at runtime).
Wouldn't it be useful to have in-core event translation somewhere
here, as long as events flow from the device into the core? For example,
you could be able to assign arbitrary button or key events to any of
those nine knobs on that famous XI_NINE_KNOB device, then you would be
able to use it even with programs that don't support it? Something like
a extended xmodmap.

I'm adding this ability right now into the driver I'm modifying (e.g.
ability to emit either button or key events from any tablet button), but
what bugs me is that it isn't quite standard, and possibly looks like a
hack... while xmodmap is a standardized hack :)

--
Greetings,
   Andrew
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg