On Mon, Jan 18, 2010 at 01:02:54PM +0100, Benjamin Tissoires wrote: > Peter Hutterer wrote: > >First of all, thanks for your efforts here. I really appreciate that you > >pushed it that far and I'm sorry about the delay in my comments. > > > >On Fri, Jan 08, 2010 at 12:55:21PM +0100, Benjamin Tissoires wrote: > >>First, I try to dynamically create/detroy such subdevices. However, > >>it infers very often freezes in the Xserver due to some mallocs. So > >>the idea to solve this problem is to staticaly allocate the > >>subdevices. > > > >Do you have any logs or other data on where these freezes occured? they'd be > >useful for others as well since chances are someone is going to run into > >this deadlock. > > > Sorry, when this freezes occurs I only had backtracks from the > driver (a xmalloc) and not the other threads (I forgot to check > them). I add this to my todo list.
Right, as Julien said you can't malloc in evdev. Any path that's hit during ReadInput cannot malloc anything. > >The evdev driver is first and foremost a generic mouse driver. Which means > >that devices that provide x and y are the most important to work, regardless > >of relative or absolute. The need for x/y is also implied by the core > >protocol. However, there's no reason that you couldn't fake up x/y > >and simply leave it as a mute axis. IMO the kernel should not report axes > >that don't exist. > >The axis mapping evdev is a convention not a rule, so you could just > >reshuffle the axis checking to cater for the multitouch situation. > >That goes for the rest of the driver too, if something seems wrong to cater > >for a new situation then the driver can be rewritten to suit this. > > > As I had to rewrite the patch to keep all the events in one device, > I will have to play with axes... and tackle this issue. right, you could have an 0/1 axis for this type of things, that's about the best approach. there's also the chance of using a button but that's more likely to be misinterpreted. the correct approach is that you only send those axes with a value, thus explicitly specifying the on/off. This is possible with XI2 but the input driver APIs aren't in place for that (no need so far). > One last question I forgot to ask: > Do we need to dynamically change the number of touch that can be detected ? > I.e. do we need to have only 10 touches (as in Windows I think) or > do we let the choice to the user (the toolkit) if the device can > handle more ? same again, you can change the number of axes in XI2, it's just that the input driver APIs are missing that feature so far. Cheers, Peter _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
