Hi all,
Today Peter Hutterer posted a preliminary feature list of Xinput 2. I have forwarded the email to here so that Vitaly and others can check it out and see if it offers what we need in Wine. If you have comments I would send them to the xorg list.
Regards, Roderick Colenbrander
--- Xorg mail --- Subject: [RFC] Preliminary XI 2 feature list
Following XDS, various notes, the discussions and preliminary executive decisions by me, here's a first draft of XI2 features. If you have anything to add, please speak up.
Time-line: I'd like to get it into server 1.6 but it doesn't look particularly likely. 7.5 is more likely.
- Compatibility with XI 1.x, although some requests will be deactivated or of limited functionality. - 16 bit device IDs - All events available as XGE events. - Event selection through event masks (instead or in addition to the event classes). i.e. the common cases of "select from all devices" and "select from all master devices" will be simplified. - Devices may have relative + absolute axes simultaneously, and change the mode on any of these axes at runtime. - Relative coordinates as a separate event. - 32 bit keycodes (reliant on XKB2) - ListInputDevices will include the currently attached Slave - Axis and button labelling through device properties. - subpixel resolution (from relative devices) available to clients. i.e. you get the data in screen coordinates, but with subpixel resolution available as fixed floating point. - no window access protocol, this will be thrown out. - dynamic device classes - device may add/remove classes at runtime. - aspect-ratio scaling of valuators.
Probable implementation details: - libXi: "namespacing": i.e. X<dosomething> will be XI<dosomething> - server-internal use of XGE events, XI 1.x events emulated when needed. - some standardisation on axis label Atom names. - Clients have to announce XI2 support, otherwise they will be treated as XI 1.x clients.
Once the feature discussion is complete, I'll get a protocol spec out.
Cheers, Peter _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Roderick Colenbrander wrote:
Hi all,
Today Peter Hutterer posted a preliminary feature list of Xinput 2. I have forwarded the email to here so that Vitaly and others can check it out and see if it offers what we need in Wine. If you have comments I would send them to the xorg list.
Regards, Roderick Colenbrander
--- Xorg mail --- Subject: [RFC] Preliminary XI 2 feature list
Following XDS, various notes, the discussions and preliminary executive decisions by me, here's a first draft of XI2 features. If you have anything to add, please speak up.
Time-line: I'd like to get it into server 1.6 but it doesn't look particularly likely. 7.5 is more likely.
- Compatibility with XI 1.x, although some requests will be deactivated or of limited functionality.
- 16 bit device IDs
- All events available as XGE events.
- Event selection through event masks (instead or in addition to the event classes). i.e. the common cases of "select from all devices" and "select from all master devices" will be simplified.
- Devices may have relative + absolute axes simultaneously, and change the mode on any of these axes at runtime.
- Relative coordinates as a separate event.
- 32 bit keycodes (reliant on XKB2)
- ListInputDevices will include the currently attached Slave
- Axis and button labelling through device properties.
- subpixel resolution (from relative devices) available to clients. i.e. you get the data in screen coordinates, but with subpixel resolution available as fixed floating point.
- no window access protocol, this will be thrown out.
- dynamic device classes - device may add/remove classes at runtime.
- aspect-ratio scaling of valuators.
Probable implementation details:
- libXi: "namespacing": i.e. X<dosomething> will be XI<dosomething>
- server-internal use of XGE events, XI 1.x events emulated when needed.
- some standardisation on axis label Atom names.
- Clients have to announce XI2 support, otherwise they will be treated as XI 1.x clients.
Once the feature discussion is complete, I'll get a protocol spec out.
Cheers, Peter
I'm still not clear which one will provide the exact events from the device? Relative events doesn't mean the device events. If this is pointer events, then it won't help. Pointer gets stuck on the border of the screen. But not mouse/trackball.
Also it would be nice to have a way to completely stop pointer from moving. Right now it's impossible, even with Xevie which was supposed to add exactly that.
Vitaliy.
Hi,
I forwarded your concerns to the xorg list and got the following response from Daniel Stone:
"Stopping the pointer from moving is easily done by temporarily detaching the device. Getting unclipped relative events will also be catered for."
Roderick
Roderick Colenbrander wrote:
Hi all,
Today Peter Hutterer posted a preliminary feature list of Xinput 2. I
have forwarded the email to here so that Vitaly and others can check it out and see if it offers what we need in Wine. If you have comments I would send them to the xorg list.
Regards, Roderick Colenbrander
--- Xorg mail --- Subject: [RFC] Preliminary XI 2 feature list
Following XDS, various notes, the discussions and preliminary executive decisions by me, here's a first draft of XI2 features. If you have
anything to
add, please speak up.
Time-line: I'd like to get it into server 1.6 but it doesn't look
particularly
likely. 7.5 is more likely.
- Compatibility with XI 1.x, although some requests will be deactivated
or of
limited functionality.
- 16 bit device IDs
- All events available as XGE events.
- Event selection through event masks (instead or in addition to the
event
classes). i.e. the common cases of "select from all devices" and
"select
from all master devices" will be simplified.
- Devices may have relative + absolute axes simultaneously, and change
the
mode on any of these axes at runtime.
- Relative coordinates as a separate event.
- 32 bit keycodes (reliant on XKB2)
- ListInputDevices will include the currently attached Slave
- Axis and button labelling through device properties.
- subpixel resolution (from relative devices) available to clients. i.e. you get the data in screen coordinates, but with subpixel
resolution
available as fixed floating point.
- no window access protocol, this will be thrown out.
- dynamic device classes - device may add/remove classes at runtime.
- aspect-ratio scaling of valuators.
Probable implementation details:
- libXi: "namespacing": i.e. X<dosomething> will be XI<dosomething>
- server-internal use of XGE events, XI 1.x events emulated when needed.
- some standardisation on axis label Atom names.
- Clients have to announce XI2 support, otherwise they will be treated
as XI
1.x clients.
Once the feature discussion is complete, I'll get a protocol spec out.
Cheers, Peter
I'm still not clear which one will provide the exact events from the device? Relative events doesn't mean the device events. If this is pointer events, then it won't help. Pointer gets stuck on the border of the screen. But not mouse/trackball.
Also it would be nice to have a way to completely stop pointer from moving. Right now it's impossible, even with Xevie which was supposed to add exactly that.
Vitaliy.
Hi Vitaliy,
For the record here another reply but this time from Peter Hutterer the guy who wrote the XI 2 specification. Is this all enough for Wine?
Roderick
On Thu, Sep 11, 2008 at 09:29:45AM +0200, Roderick Colenbrander wrote:
I'm still not clear which one will provide the exact events from the device? Relative events doesn't mean the device events. If this is pointer events, then it won't help. Pointer gets stuck on the border of the screen. But not mouse/trackball.
This is the reason why relative events will be separate from standard events as they won't be affected by clipping.
Also it would be nice to have a way to completely stop pointer from moving. Right now it's impossible, even with Xevie which was supposed to add exactly that.
Grabbing an attached SD temporarily detaches it from the MD. Alternatively, you could explicitly detach it. Either way, the visible representation of the cursor ceases to move (from this device anyway, other attached ones may still change the cursor position).
Cheers, Peter
Roderick Colenbrander wrote:
Hi Vitaliy,
For the record here another reply but this time from Peter Hutterer the guy who wrote the XI 2 specification. Is this all enough for Wine?
Roderick
On Thu, Sep 11, 2008 at 09:29:45AM +0200, Roderick Colenbrander wrote:
I'm still not clear which one will provide the exact events from the device? Relative events doesn't mean the device events. If this is pointer events, then it won't help. Pointer gets stuck on the border of the screen. But not mouse/trackball.
This is the reason why relative events will be separate from standard events as they won't be affected by clipping.
Also it would be nice to have a way to completely stop pointer from moving. Right now it's impossible, even with Xevie which was supposed to add exactly that.
Grabbing an attached SD temporarily detaches it from the MD. Alternatively, you could explicitly detach it. Either way, the visible representation of the cursor ceases to move (from this device anyway, other attached ones may still change the cursor position).
Thanks Roderick. This does sounds like enough for what needed for direct input.
Vitaliy.
-
Roderick Colenbrander -
Vitaliy Margolen