Hi Josep, On Mon, Dec 8, 2014 at 5:04 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: > Thanks for the logs (both way arrived in my mailbox, attached file or pastebin). > > I'll try to have a look at them on Wednesday. Actually, it's nearly been a month. Thanks for the reminder. (However, it's easier to track the various bugs with only one thread, not several). So apologies for the delay. > > On Mon, Dec 8, 2014 at 3:52 PM, <josep.sanchez.ferreres@xxxxxxxxxxxxxxx> wrote: >> I attach a .tar.gz with all the captures I took, the filenames should be >> self explanatory. If you prefer me to dump all that into the e-mail text >> field just ask, but it's quite a big amount of data. >> >> Both 3.16 and 3.18 kernels seemed to respond to the same events. Oddly >> enough I've noticed that although 3 devices for rawhid were listed, only two >> captured events. Here's the output from hid-replay that shows my devices: >> >> Available devices: >> /dev/hidraw0: USB Keyboard >> /dev/hidraw1: USB Keyboard >> /dev/hidraw2: USB OPTICAL MOUSE >> /dev/hidraw3: Wacom Co.,Ltd. Bamboo Pad, USB >> /dev/hidraw4: Wacom Co.,Ltd. Bamboo Pad, USB >> /dev/hidraw5: Wacom Co.,Ltd. Bamboo Pad, USB >> >> Only hidraw4 and 5 reported events to hid-replay. Also note that hidraw5 >> corresponds to the touchpad while hidraw5 corresponds to the stylus. Hmm, I'd like to see the evemu-record output of hidraw3 still. hidraw4 is for now completely ignored by wacom on purpose because all the rest of the wacom tablets have a mouse emulation mode which looks like this one. I think we might be able to report true multitouch data through hidraw3, but I need to have a look at it. >> >> I also just found out that the stylus hardware button is captured by the >> touchpad device and not by the stylus one (that actually makes more sense as >> it acts like a mouse button), so all the data I put about the stylus key >> should just contain stylus movement data. I added a file stylus-key.hid >> which is actually capturing the clicks for that button. Weird. I managed to make the stylus working properly with the current code base (patches to follow soon). The stylus secondary button was send through the stylus interface, so I am not quite following you here. >> >> I should also say that some events, like clicking the screen with the stylus >> will be mixed with the mouse movement (I tried to avoid that by clicking >> fast enough but I guess it's impossible to completely avoid it). That's not a problem per se. It's easy to have a look at the events and filter out what is not required. But thanks for the effort though, it simplifies part of the filtering! Cheers, Benjamin >> >> PD: I see you're using a gmail address to reply, should I reply to that >> address better? > > I think that's better to keep all the people in CC of the thread. we > generally have rules to filter linux-input/lkml mails, so it avoids > losing traces of a thread. > > Cheers, > Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
