[RFC] X Input Driver specification
Magnus.Vigerlof at home.se
Sun Apr 15 10:22:29 PDT 2007
On Tuesday 10 April 2007 23:26, Simon Thum wrote:
> Hi Magnus,
> thanks for answering my newbie questions (and reviewing my patch!).
> It is now clear to me such concerns are out of scope for your proposal.
> Maybe I did'nt make it clear, my concern is the following:
> As you can see in my patch, ApplyExtendedValuatorSettings() is more or
> less a hack which links (backend-specific, I presume) configuration data
> into dix. From an aesthetical (or sw engineering) POV, this should be
> done in the backend. But none of the functions there got called with the
> valuators initialized, if at all.
> Except for xf86InitValuatorAxisStruct ;)
> So, I thinks I have the following alternatives:
> 1) current hack
> 2) handcrafted, incomplete but better-suited callback
> 3) someone who has X(input) experience tells me how to do better
> 4) I'm missing something
> 3) was what I thought what would do good in your proposal, but it
> doesn't seem to suit there.
Well.. Init/uninit of the stuff must be made somewhere, but this would be
something different (new?); a filter that can be applied to all relative
> Maybe you can suggest me something? Even if I'm the only use case, I
> think backends should have a chance to react on device
> additions/removals without relying on such tinkering.
Oh.. You have more faith in me than I have ;) I've only been looking at the
source for about four months, so there got to be others who know the
XInput-parts better than me.
Oh well, some thoughts.. As I see it the configuration of the function is the
tricky part. You have it covered for initial configuration (even for
hot-plugged devices), but changing parameters run-time is tricky (even
One way to make this possible would be to define an interface to handle
device-independent extensions. Turning on/off different features, changing
parameters, etc. Maybe something like this already exists that can be used?
Once hot-plugging is getting included and used, that could be used for
changing the parameters I guess. But that feels like the wrong way to do it
> Also, on subpixel motions, a grep told me aiptek and acecad
> are WACOM-related, but I didn't see where subpixel events get generated.
> Is this the right spot anyway?
The wacom driver has its own project over at sourceforge due to licensing
restrictions (linuxwacom). So for those tablets you need to look at that
source if you want to see how those do.
I also think evdev has been sending sub-pixel motion reports (with the old
event generating code), but doesn't anymore. There are some scaling involved,
but I haven't figured out if it scales everywhere where these values are
It might not be obvious that the wacom device do. The wacom driver get its
value ranges from the underlying device, and then initiate the axis with this
(up to 80' or 100' on the X-axis if I remember correctly). The whole range is
then reported with xf86PostMotionEvent, which until recently has been scaled
in that function.
More information about the xorg