xf86PostKeyEvent and xf86PostKeyboardEvent

[Daniel Stone]

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 at aehallh.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060321/02abc379/attachment.pgp>