<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Combined Keyboard+Mouse+Touchpad device problems" href="https://bugs.freedesktop.org/show_bug.cgi?id=99914#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Combined Keyboard+Mouse+Touchpad device problems" href="https://bugs.freedesktop.org/show_bug.cgi?id=99914">bug 99914</a> from <a class="email" href="mailto:freedesktop@gergo.csillger.hu" title="Gergely Nagy <freedesktop@gergo.csillger.hu>"> Gergely Nagy</a> <pre>(In reply to Peter Hutterer from <a href="show_bug.cgi?id=99914#c3">comment #3</a>) > ok, there are a couple of issues here. The first one is that the device has > everything on the same event node. That's not something that libinput > handles well because historically the kernel split up the event nodes for us > into one for keyboard,one for touchpad, one for mouse (though we do handle > mouse+keyboard on the same node). FWIW, if I change the firmware to still report a 32k*32k resolution, but limit movement to ~960*550, everything works fine. So it seems three things on the same node is handled well. > For a touchpad to be identified as such you need BTN_TOOL_FINGER and > BTN_TOUCH, both are missing. I'll see how I can add these, thanks! > The event stream is confusing with a lot of relative deltas of -2/-2, > roughly 4ms apart. So that would move the pointer to the top-left in a very > short time. Given the speed of the events this would likely see maximum > acceleration and thus be even faster. Those relative movements are me holding the mouse keys to reposition the cursor to the ~center of the screen. The touchpad code only sends the ABS_X/ABS_Y stuff. > There are a few ABS_X/ABS_Y events but the max value there is 3072 which is > a fraction of the 32k axis range. The pointer likely jumps a few pixels down > but immediately moves back up due to the REL_X/REL_Y events. Probably too > fast to be visible. The pointer jumps to the bottom right corner, and stays there until I press the normal mouse keys to move it back to the center for the next test. All the REL_X/REL_Y events are direct results of me pressing keys. If you check the SYN_REPORT lines in the logs, the first REL_X/REL_Y event after an ABS_X/ABS_Y one usually has a >+1600ms delta. > (In reply to Gergely Nagy from <a href="show_bug.cgi?id=99914#c1">comment #1</a>) > > - I press the "northwest" key, which should move the mouse towards the top > > left corner: it moves to bottom right. > > indicates the screen is mounted the wrong way? the deltas are negative, so > the screen is upside-down. Err.. the deltas are negative, because I move the mouse cursor back to the center. If its in the bottom right corner, to move to the center, the deltas will need to be negative. > > - I position the mouse back. > > - I press the "northeast" key, which should move it towards the top right > > corner: it moves to the bottom right. > > I don't see any positive REL_X/Y events, so the buttons are hooked up the > wrong way. You don't see a positive REL_X/Y, because I did not have to move the mouse in those directions. All the REL_X/REL_Y events are results of me moving the mouse cursors with mouse keys, as opposed to the touchpad keys. > (In reply to Gergely Nagy from <a href="show_bug.cgi?id=99914#c2">comment #2</a>) > > Because the firmware reports its x/y max as 32k, this explains why the > > cursor always ends up on the bottom right corner. So I'm left wondering how > > I can tell libinput to map the virtual touchpad's 32k*32k area to whatever > > my resolution under X11 is? > > you can't, libinput doesn't know about that. The solution to this is to fix > the firmware so the absolute range reflects the reachable axes and then let > the rest of the stack DTRT. I reviewed the evemu-record, and it seems I sent a wrong one, where I had the firmware set to limit movement to a lower resolution, as an attempt to figure things out. I've done a new record now (will be attaching it in a bit), and it clearly shows the firmware sending the right coordinates, from its point of view. What you can see in the record: +----+----+ | NW | NE | +----+----+ | SW | SE | +----+----+ - NW key: middle of the first quadrant: 8191 is 32767 / 4. ABS_X/ABS_Y set to 8191. - NE key: middle of the second quadrant: 24574 is 16k + 8k, the middle of the second quadrant. I suspect there's no ABS_Y sent, because that's already 8191. - SW key: middle of the third quadrant: ABS_X moved back to 8k, ABS_Y to 24k. - SE key: middle of the fourth quadrant: ABS_X and ABS_Y moved to 24k. In all of these cases, the cursor ends up in the bottom right corner of the screen, because all of these values are higher than the ~960x550 which seems to be the limit. So, it seems to me that the whole 32k is reachable, the correct events appear to be sent... so something in the stack is likely not doing the right thing, and that something is increasingly looking like not being libinput, as far as I see. Perhaps xf86-input-libinput? Or shall I look further up, and experiment with a different DE? (I'm on GNOME3 at the moment, if that matters) Or... can it be due to not having the BTN_TOUCH, and BTN_TOOL_FINGER things? Perhaps combined with being on the same node as a mouse?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>