| Summary: | [bug] weston-terminal doesn't accept input from keypad | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Brian Lovin <brian.j.lovin> |
| Component: | weston | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | blei42, daniel |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
handle keypad symbols in weston-terminal
inherit initial modifier state from xkb inherit initial modifier state from xkb (not broken) |
||
|
Description
Brian Lovin
2012-07-23 23:08:53 UTC
Oh, yea, I see that too... Daniel? Created attachment 64579 [details] [review] handle keypad symbols in weston-terminal This compiles and may even work, but I don't have anything with a keypad to hand, so. (In reply to comment #2) > Created attachment 64579 [details] [review] [review] > handle keypad symbols in weston-terminal > > This compiles and may even work, but I don't have anything with a keypad to > hand, so. Hi Daniel, I tested this patch and it seems that it works. However, there is a strange behavior where the keypad numbers act as arrow keys, even though numlock is toggled on. Toggling it off, they still behave as arrows. Toggling it back on then causes the numbers to show numbers as expected. Subsequent toggling behaves as expected thereafter. This is a per-weston instance problem, not per-terminal instance. http://lists.freedesktop.org/archives/wayland-devel/2012-August/004968.html Does this work better? Hmm, my patch only works for printable characters, the others will have to be handled similarly as in Daniel's patch. (In reply to comment #3) > Hi Daniel, > > I tested this patch and it seems that it works. However, there is a strange > behavior where the keypad numbers act as arrow keys, even though numlock is > toggled on. Toggling it off, they still behave as arrows. Toggling it back on > then causes the numbers to show numbers as expected. Subsequent toggling > behaves as expected thereafter. This is a per-weston instance problem, not > per-terminal instance. I could actually reproduce this issue in X. The first time I activate the numpad keys on my laptop keyboard in a new workspace, they work as arrow keys. Subsequent activation works as expected. (In reply to comment #3) > I tested this patch and it seems that it works. However, there is a strange > behavior where the keypad numbers act as arrow keys, even though numlock is > toggled on. Toggling it off, they still behave as arrows. Toggling it back on > then causes the numbers to show numbers as expected. Subsequent toggling > behaves as expected thereafter. This is a per-weston instance problem, not > per-terminal instance. Hmm. How is numlock getting set initially? Are you pressing it by hand, or is it getting inherited from the environment? Are you running DRM or X11? If using X11, it might just be a problem with getting the initial NumLock state - I'll attach a patch in a sec which might help with that. Created attachment 65734 [details] [review] inherit initial modifier state from xkb This requires XCB/XKB, but should hopefully fix things up a bit. Created attachment 65735 [details] [review] inherit initial modifier state from xkb (not broken) Aaaarrrrgggghhhhh. Wrong version. (In reply to comment #8) > Created attachment 65735 [details] [review] [review] > inherit initial modifier state from xkb (not broken) > > Aaaarrrrgggghhhhh. Wrong version. Did this go to the list? There's two issues in this bug. One is that numlock keys didn't work in an earlier xkbcommon version (which I was able to reproduce in comment 1). This is fixed now in xkbcommon 0.2. The other issues was about not correctly inheriting the xkb modifier state, which is fixed by Daniels patch in comment 8. I've rebased that patch on master and pushed it, so I'll close this bug now. Changing to verified. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.