[RFC] X Input Driver specification

[Magnus Vigerlöf]

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 
pointer-devices.

> 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 
possible currently?).
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 
though...

> 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 
visible.

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.

Cheers
  Magnus