Re: [PATCH wayland] Add enum attribute to arg elements
Hello, I do think that docenum and enum should be split up. I don't really get the purpose of docenum though. Even if an enum can be extended, that extension would technically be an extension to the protocol, would it not? Completeness of enums is information that can be encoded in strongly typed languages, but I do not think such guarantees are necessary. Bindings should be able to deal with new constants not listed in the protocol. If we guarantee completeness of enums, I expect we will get all kinds of backwards compatibility issues. I do not quite agree with this. If an application encounters an enum it's not familiar with, it should output a warning or an error. The bindings should generate the code to be used by the application. If the application wants to extend the protocol, they'll have to extend the specification. As for the bitfields, I do agree it makes more sense to have them in the argument tags, for the reasons already mentioned. That would be solved by documenting the XML language, including guidelines for generator writers. I think there are things that wayland-scanner cannot communicate, especially when they do not really exist in C. I can only agree with this. Thanks - Jeroen On Thu, 23 Apr 2015 at 10:38 Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 23 Apr 2015 10:17:12 +0200 Auke Booij a...@tulcod.com wrote: On 23 April 2015 at 08:38, Pekka Paalanen ppaala...@gmail.com wrote: On Wed, 22 Apr 2015 11:47:51 +0200 Auke Booij a...@tulcod.com wrote: On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote: I also think this discussion is going off-topic. You wanted to add annotations to the XML, so you could find out about enum and bitfield arguments, so let's keep to that. There is value in simplicity. How about this: Add three new, mutually exclusive attributes for arg tags: docenum=enumname Docenum would be for documentation linking only, and should not affect code generation. The effect would be in the documentation to add a link to the definition of the enumname enum. This attribute is applicable for both int and uint type args. enumeration=enumname Enumeration would be a doc link, but also specify that the enum enumname is a complete enumeration: no other values are legal. You can use this for code generation. You will rely on interface version negotiation to avoid unknown values in case you have an old definition of the interface and your opponent is using a new definition which added values. This attribute is applicable for both int and uint type args. bitfield=enumname Bitfield would be a doc link, but also specify that the values listed in enum enumanme can be orred together to form new legal values. Bits that are not settable by using the listed values must be zero. You rely on the interface versioning to avoid getting undefined bits set, just like enumeration relies for adding new values. This attribute is applicable only to uint type args. So, both enumeration and bitfield could be used for codegen, docenum would not. Docenum or nothing would be used for cases that do not fit as enumeration or bitfield, including cases where unknown values are always allowed but the interface specification defines what to do when encountering one (ignore, use as a literal value, ...). Wayland-scanner would generate the doclink references in header comments, and check that the referenced enum exists and the arg type. Two comments on this. 1. I do not think it is necessary to distinguish between docenum and enumeration. At least for me, I am not asking for any new guarantees with regards to completeness: sure, new constants may be added on the fly. All I want is semantic information: which (u)int refers to which enum? And this data would be provided by your docenum (which I would just call enum). Jeroen seemed to be wanting that. That's why it gets complicated. I agree. Well, if there is support for Jeroen's ideas, I will add that to the scanner.c patch. I am not against them, but I would expect the guarantees to be broken by C code all the time, so there needs to be a solution for that. I'd rather not, or at least separate these two. We can add the doc attribute, and discuss the strictness later. Adding strictness constraints later should be as simple as adding more attributes. However, if strictness attributes affect codegen, it might be difficult to add them to existing enums, because it would change the API a code generator produces. That is a pretty strong reason to not change anything that affects codegen: you may be using an XML file that does not have these attributes, or you may be using a generator that does not handle these attributes. Third party XML files are a thing,
[PATCH libinput v5] evdev: use a different filter for low resolution touchpad on the Lenovo X230
Those touchpads presents an actual lower resolution that what is
advertised.
We see some jumps from the cursor due to the big steps in X and Y
when we are receiving data.
For instance, we receive:
E: 13.471932 0003 16366# EV_ABS / ABS_X16366
E: 13.471932 0003 0001 9591 # EV_ABS / ABS_Y9591
E: 13.471932 # SYN_REPORT (0) --
E: 13.479924 0003 16316# EV_ABS / ABS_X16316
E: 13.479924 0003 0001 9491 # EV_ABS / ABS_Y9491
E: 13.479924 # SYN_REPORT (0) --
E: 13.487939 0003 16271# EV_ABS / ABS_X16271
E: 13.487939 0003 0001 9403 # EV_ABS / ABS_Y9403
E: 13.487939 # SYN_REPORT (0) --
- jumps of ~50 in X in each report, and ~100 for Y.
Apply a factor to minimize those jumps at low speed, and try
keeping the same feeling as regular touchpads at high speed.
It still feels slower but it is usable at least
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com
---
Hi,
So this will hopefully be validated and pulled upstream.
This patch needs the one Peter sent out yesterday (evdev: add support for
LIBINPUT_MODEL_* udev tags). It is thus much smaller given that the generic
bits are in the other patch.
The final choice for the acceleration profile is the one I sent in the v1 of
the series. A nice drawing of the acceleration profile is available here:
http://people.freedesktop.org/~tissoire/x230-v5.png
If anybody wants to polish it, I am all for it.
Some special notes if you want to use the patch without rebooting:
- do not forget to update the hwdb (sudo udevadm hwdb --update)
- reload the udev rules (sudo udevadm control --reload)
- and trigger the input nodes (sudo udevadm trigger /dev/input/event*)
- the udev database should still show LIBINPUT_MODEL_LENOVO_X230 attached to the
touchpad node (udevadm info --export-db | less)
Then kill X (or restart gdm), and you are good.
Cheers,
Benjamin
src/evdev-mt-touchpad.c| 14 ++--
src/evdev.c|1 +
src/evdev.h|1 +
src/filter.c | 37
src/filter.h |5
udev/90-libinput-model-quirks.hwdb |8 +++
6 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index cccf033..d5ce880 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -998,6 +998,7 @@ static int
tp_init_accel(struct tp_dispatch *tp, double diagonal)
{
int res_x, res_y;
+ accel_profile_func_t profile;
res_x = tp-device-abs.absinfo_x-resolution;
res_y = tp-device-abs.absinfo_y-resolution;
@@ -1021,9 +1022,16 @@ tp_init_accel(struct tp_dispatch *tp, double diagonal)
tp-accel.y_scale_coeff = DEFAULT_ACCEL_NUMERATOR / diagonal;
}
- if (evdev_device_init_pointer_acceleration(
- tp-device,
- touchpad_accel_profile_linear) == -1)
+ switch (tp-device-model) {
+ case EVDEV_MODEL_LENOVO_X230:
+ profile = touchpad_lenovo_x230_accel_profile;
+ break;
+ default:
+ profile = touchpad_accel_profile_linear;
+ break;
+ }
+
+ if (evdev_device_init_pointer_acceleration(tp-device, profile) == -1)
return -1;
return 0;
diff --git a/src/evdev.c b/src/evdev.c
index e3bba93..6a9df49 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1429,6 +1429,7 @@ evdev_read_model(struct evdev_device *device)
const char *property;
enum evdev_device_model model;
} model_map[] = {
+ { LIBINPUT_MODEL_LENOVO_X230, EVDEV_MODEL_LENOVO_X230 },
{ NULL, EVDEV_MODEL_DEFAULT },
};
const struct model_map *m = model_map;
diff --git a/src/evdev.h b/src/evdev.h
index edd4011..151d103 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -95,6 +95,7 @@ enum evdev_middlebutton_event {
enum evdev_device_model {
EVDEV_MODEL_DEFAULT,
+ EVDEV_MODEL_LENOVO_X230,
};
struct mt_slot {
diff --git a/src/filter.c b/src/filter.c
index 962d74d..b953bee 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -345,3 +345,40 @@ touchpad_accel_profile_linear(struct motion_filter *filter,
return speed_out * TP_MAGIC_SLOWDOWN;
}
+
+double
+touchpad_lenovo_x230_accel_profile(struct motion_filter *filter,
+ void *data,
+ double speed_in,
+ uint64_t time)
+{
+ /* Keep the magic factor from touchpad_accel_profile_linear. */
+ const double TP_MAGIC_SLOWDOWN = 0.4;
+
+ /* Those touchpads presents an actual lower
Re: [PATCH wayland] Add enum attribute to arg elements
On 04/22/2015 11:49 PM, Pekka Paalanen wrote: Allowing fully qualified names is another thing. Should we allow it? Is it good practice? Is it useful? How would the fully qualitified names look like? Even if it's not used for codegen, you need it for docgen if you want to be able to reference other interfaces' enums. Many interfaces may have same-named enums. Using enum=interfacename.enumname would probably work. The interfacename. is optional if you are describing a method on the same interface. Another possibility is to just add interface=interfacename to the argument along with enum=enumname. Due to the name collisions of both enum names and enum values, most language binding will probably have to fully qualify any values. So you are likely to see widget.setAlignment(Widget.Align.Left) despite the redundant information. So a more drastic approach might be to make enums be in the same namespace as interfaces, renaming them as necessary to avoid collisions. An even more drastic approach would be to put all the values in the same namespace as interfaces, again renaming (or perhaps changing the values) as necessary. This would allow the programmer to write Widget.setAlignment(Left). It would also match how enums in C work. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
Using enum=interfacename.enumname would probably work. The interfacename. is optional if you are describing a method on the same interface. Another possibility is to just add interface=interfacename to the argument along with enum=enumname. The second possibility wouldn't work for bitfields that take enums from different interfaces. An even more drastic approach would be to put all the values in the same namespace as interfaces, again renaming (or perhaps changing the values) as necessary. This would allow the programmer to write Widget.setAlignment(Left). It would also match how enums in C work. Putting enums next to interfaces, instead of inside of them, to me, also seems like the best option. I don't think it'll get any support however, as it isn't backwards compatible. On Thu, 23 Apr 2015 at 20:22 Bill Spitzak spit...@gmail.com wrote: On 04/22/2015 11:49 PM, Pekka Paalanen wrote: Allowing fully qualified names is another thing. Should we allow it? Is it good practice? Is it useful? How would the fully qualitified names look like? Even if it's not used for codegen, you need it for docgen if you want to be able to reference other interfaces' enums. Many interfaces may have same-named enums. Using enum=interfacename.enumname would probably work. The interfacename. is optional if you are describing a method on the same interface. Another possibility is to just add interface=interfacename to the argument along with enum=enumname. Due to the name collisions of both enum names and enum values, most language binding will probably have to fully qualify any values. So you are likely to see widget.setAlignment(Widget.Align.Left) despite the redundant information. So a more drastic approach might be to make enums be in the same namespace as interfaces, renaming them as necessary to avoid collisions. An even more drastic approach would be to put all the values in the same namespace as interfaces, again renaming (or perhaps changing the values) as necessary. This would allow the programmer to write Widget.setAlignment(Left). It would also match how enums in C work. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
(yes the language binding could prevent this, but programmers writing direct Wayland api are already wading into dangerous waters and can probably be trusted to do this correctly. So for now I don't think there is any need for a strict control). I do not quite agree with this. Yes, they should know they are wading into dangerous waters, but any error that can be prevented, should be. It also helps of course, for features like code completion, although as I am writing Rust bindings, that doesn't apply to me. Maybe it could be added, ie you can make global enumerations as well as local enumerations. Local ones are still useful for the error values. That would be a good solution, but maybe that's making the specification a bit too complex? I would be in favour of moving everything to same namespace as the interface, but of course, compatibility issues will arise with exciting binding generators. In any case, I think the specification should be as strict as possible, because making it stricter is hard, but making it less strict is easy. On Thu, 23 Apr 2015 at 20:59 Bill Spitzak spit...@gmail.com wrote: On 04/23/2015 11:28 AM, Jeroen Bollen wrote: Using enum=interfacename.enumname would probably work. The interfacename. is optional if you are describing a method on the same interface. Another possibility is to just add interface=interfacename to the argument along with enum=enumname. The second possibility wouldn't work for bitfields that take enums from different interfaces. I didn't think that would be allowed. The bitmap arg can only or together a set of values from a single enumeration. An even more drastic approach would be to put all the values in the same namespace as interfaces, again renaming (or perhaps changing the values) as necessary. This would allow the programmer to write Widget.setAlignment(Left). It would also match how enums in C work. Putting enums next to interfaces, instead of inside of them, to me, also seems like the best option. I don't think it'll get any support however, as it isn't backwards compatible. Maybe it could be added, ie you can make global enumerations as well as local enumerations. Local ones are still useful for the error values. Some sort of aliasing could be used to migrate other local enumerations to global without breaking any existing code. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
I think there may be some confusion about how this would be used by a language binding, and why bitmap is necessary, and also why it has to be on the enumeration. Imagine an interface called Widget, and it has two methods set_type(Type) and set_flags(Flags). set_type takes an enumeration called Type and set_flags takes a bitmap called Flags. Type has two values Left and Right. Flags has two non-zero values A and B. widget is an instance of Widget in this language. Here is how the two messages might look written in this language: widget.set_type(Widget.Type.Left) widget.set_flags(Widget.Flags.A) The following do not compile. In most languages this is because there is a type mismatch between the argument and the expression used to set it: widget.set_type(43) // error! widget.set_type(Widget.Flags.A) // error! widget.set_flags(Widget.Type.Left) // error! widget.set_flags(0x1349) // error! However (and this is why I don't think documentation only or strictness is needed) the languages can provide a method to force the above things to compile. This usually involves adding some extra syntax such as a cast, the extra code makes it clear to the programmer that they should be careful: widget.set_type(Widget.Type(43)) widget.set_flags(Widget.Flags(0x1349)) (yes the language binding could prevent this, but programmers writing direct Wayland api are already wading into dangerous waters and can probably be trusted to do this correctly. So for now I don't think there is any need for a strict control). The reason for the bitmap is because this should work: widget.set_flags(Widget.Flags.A | Widget.Flags.B) but this should not work (either you cannot or the two values together, or the result of or is the wrong type): widget.set_type(Widget.Type.Left | Widget.Type.Right) // error! The binding generation has to know whether it is a bitmap so that it can make these two cases behave differently. You may think this is minor detail and it would be ok to or any values together, and yes that would probably not confuse programmers able to write Wayland api. However the real reason is that supporting the or is much more complex in some languages (C++ for example) and thus binding generators would like to avoid it if possible. The reason the bitmap indicator has to be on the enumeration and not the method is because of this: var x = Widget.Flags.A; if (foo) x |= Widget.Flags.B; // *** widget.set_flags(x) The language has to know the legality of the statmeent marked with ***. It cannot depend on knowing the result will later be used for the set_flags request. Therefore the bitmap attribute has to be on the type, not the request. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: add support for LIBINPUT_MODEL_* udev tags
On Thu, Apr 23, 2015 at 6:48 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 23-04-15 04:07, Peter Hutterer wrote: Some devices need specific configuration or different defaults. Push that into udev rules and a hwdb file, that's where detection is the easiest. The LIBINPUT_MODEL_ prefix is used to determine some type of device model. Note that this property is a private API and subject to change at any time without notice. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Looks good: Reviewed-by: Hans de Goede hdego...@redhat.com Yep, you can also add: Tested-by: Benjamin Tissoires benjamin.tissoi...@gmail.com Cheers, Benjamin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
On 04/23/2015 11:28 AM, Jeroen Bollen wrote: Using enum=interfacename.enumname would probably work. The interfacename. is optional if you are describing a method on the same interface. Another possibility is to just add interface=interfacename to the argument along with enum=enumname. The second possibility wouldn't work for bitfields that take enums from different interfaces. I didn't think that would be allowed. The bitmap arg can only or together a set of values from a single enumeration. An even more drastic approach would be to put all the values in the same namespace as interfaces, again renaming (or perhaps changing the values) as necessary. This would allow the programmer to write Widget.setAlignment(Left). It would also match how enums in C work. Putting enums next to interfaces, instead of inside of them, to me, also seems like the best option. I don't think it'll get any support however, as it isn't backwards compatible. Maybe it could be added, ie you can make global enumerations as well as local enumerations. Local ones are still useful for the error values. Some sort of aliasing could be used to migrate other local enumerations to global without breaking any existing code. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] tests: Add negative test for libinput_device_keyboard_has_key()
Ensure we get a -1 return for non-keyboard devices.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
test/keyboard.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/keyboard.c b/test/keyboard.c
index a477cfb..e098dc0 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -309,6 +309,20 @@ START_TEST(keyboard_has_key)
}
END_TEST
+START_TEST(keyboard_keys_bad_device)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+
+ if (libinput_device_has_capability(device,
+ LIBINPUT_DEVICE_CAP_KEYBOARD))
+ return;
+
+ ck_assert_int_eq(libinput_device_keyboard_has_key(device, KEY_A),
+-1);
+}
+END_TEST
+
int
main(int argc, char **argv)
{
@@ -316,6 +330,7 @@ main(int argc, char **argv)
litest_add_no_device(keyboard:key counting,
keyboard_ignore_no_pressed_release);
litest_add_no_device(keyboard:key counting,
keyboard_key_auto_release);
litest_add(keyboard:keys, keyboard_has_key, LITEST_KEYS, LITEST_ANY);
+ litest_add(keyboard:keys bad device, keyboard_keys_bad_device,
LITEST_ANY, LITEST_ANY);
return litest_run(argc, argv);
}
--
2.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v4] input: Don't test keyboard/pointer/touch pointers
Keyboards and pointers aren't freed when devices are removed,
so we should really be testing keyboard_device_count and
pointer_device_count in most cases, not the actual pointers.
Otherwise we end up with different behaviour after removing a
device than we had before it was inserted.
This commit renames the touch/keyboard/pointer pointers and adds
helper functions to get them that hide this complexity and return
NULL when *_device_count is 0.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
This is just v3 rebased to current master.
Also available at https://github.com/ManMower/weston/tree/dont_use_the_pointers
I'll try to keep that branch up to date.
desktop-shell/exposay.c | 27 ++--
desktop-shell/input-panel.c | 7 +-
desktop-shell/shell.c | 266 ++--
fullscreen-shell/fullscreen-shell.c | 21 ++-
ivi-shell/hmi-controller.c | 35 +++--
ivi-shell/input-panel-ivi.c | 7 +-
src/bindings.c | 28 ++--
src/compositor-drm.c| 16 ++-
src/compositor-wayland.c| 8 +-
src/compositor-x11.c| 20 ++-
src/compositor.c| 96 +++--
src/compositor.h| 15 +-
src/data-device.c | 41 +++---
src/input.c | 241
src/libinput-device.c | 3 +-
src/libinput-seat.c | 15 +-
src/screen-share.c | 3 +-
src/screenshooter.c | 7 +-
src/text-backend.c | 19 +--
src/zoom.c | 8 +-
tests/surface-screenshot.c | 7 +-
tests/weston-test.c | 9 +-
xwayland/dnd.c | 3 +-
xwayland/window-manager.c | 21 +--
24 files changed, 579 insertions(+), 344 deletions(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 4b65cbd..e3b1c78 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -517,11 +517,13 @@ static enum exposay_layout_state
exposay_set_inactive(struct desktop_shell *shell)
{
struct weston_seat *seat = shell-exposay.seat;
+ struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
+ struct weston_pointer *pointer = weston_seat_get_pointer(seat);
- weston_keyboard_end_grab(seat-keyboard);
- weston_pointer_end_grab(seat-pointer);
- if (seat-keyboard-input_method_resource)
- seat-keyboard-grab = seat-keyboard-input_method_grab;
+ weston_keyboard_end_grab(keyboard);
+ weston_pointer_end_grab(pointer);
+ if (keyboard-input_method_resource)
+ keyboard-grab = keyboard-input_method_grab;
return EXPOSAY_LAYOUT_INACTIVE;
}
@@ -554,26 +556,27 @@ static enum exposay_layout_state
exposay_transition_active(struct desktop_shell *shell)
{
struct weston_seat *seat = shell-exposay.seat;
+ struct weston_pointer *pointer = weston_seat_get_pointer(seat);
+ struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
struct shell_output *shell_output;
bool animate = false;
shell-exposay.workspace = get_current_workspace(shell);
- shell-exposay.focus_prev = get_default_view (seat-keyboard-focus);
- shell-exposay.focus_current = get_default_view (seat-keyboard-focus);
+ shell-exposay.focus_prev = get_default_view(keyboard-focus);
+ shell-exposay.focus_current = get_default_view(keyboard-focus);
shell-exposay.clicked = NULL;
wl_list_init(shell-exposay.surface_list);
lower_fullscreen_layer(shell);
shell-exposay.grab_kbd.interface = exposay_kbd_grab;
- weston_keyboard_start_grab(seat-keyboard,
- shell-exposay.grab_kbd);
- weston_keyboard_set_focus(seat-keyboard, NULL);
+ weston_keyboard_start_grab(keyboard, shell-exposay.grab_kbd);
+ weston_keyboard_set_focus(keyboard, NULL);
shell-exposay.grab_ptr.interface = exposay_ptr_grab;
- weston_pointer_start_grab(seat-pointer,
+ weston_pointer_start_grab(pointer,
shell-exposay.grab_ptr);
- weston_pointer_set_focus(seat-pointer, NULL,
-seat-pointer-x, seat-pointer-y);
+ weston_pointer_set_focus(pointer, NULL,
+pointer-x, pointer-y);
wl_list_for_each(shell_output, shell-output_list, link) {
enum exposay_layout_state state;
diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index ffa3ade..1c2d08b 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -66,9 +66,12 @@ show_input_panel_surface(struct input_panel_surface *ipsurf)
float x, y;
wl_list_for_each(seat, shell-compositor-seat_list, link) {
- if (!seat-keyboard ||
Re: [PATCH libinput] Add libinput_device_keyboard_has_key()
On 22/04/15 07:05 PM, Peter Hutterer wrote:
On Wed, Apr 22, 2015 at 08:45:21AM -0500, Derek Foreman wrote:
On 21/04/15 11:44 PM, Peter Hutterer wrote:
Similar to libinput_device_pointer_has_button(), this function returns
whether
a given device has a specific keycode.
This enables a caller to determine if the device is really a keyboard (check
for KEY_A-KEY_Z) or just a media key device (check for KEY_PLAY or
somesuch),
depending on the context required.
Cool, thanks. :)
Trivial comments below.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Had a deja-vu implementing this, I thought this already existed.
src/evdev.c | 9 +
src/evdev.h | 3 +++
src/libinput.c | 6 ++
src/libinput.h | 16
src/libinput.sym | 5 +
test/keyboard.c | 20
6 files changed, 59 insertions(+)
[...]
diff --git a/test/keyboard.c b/test/keyboard.c
index cb7ad52..a477cfb 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -290,12 +290,32 @@ START_TEST(keyboard_key_auto_release)
}
END_TEST
+START_TEST(keyboard_has_key)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+ unsigned int code;
+ int evdev_has, libinput_has;
+
+ ck_assert(libinput_device_has_capability(
+device,
+LIBINPUT_DEVICE_CAP_KEYBOARD));
+
+ for (code = 0; code KEY_CNT; code++) {
+ evdev_has = libevdev_has_event_code(dev-evdev, EV_KEY, code);
+ libinput_has = libinput_device_keyboard_has_key(device, code);
+ ck_assert_int_eq(evdev_has, libinput_has);
+ }
+}
+END_TEST
+
int
main(int argc, char **argv)
{
litest_add_no_device(keyboard:seat key count,
keyboard_seat_key_count);
litest_add_no_device(keyboard:key counting,
keyboard_ignore_no_pressed_release);
litest_add_no_device(keyboard:key counting,
keyboard_key_auto_release);
+ litest_add(keyboard:keys, keyboard_has_key, LITEST_KEYS, LITEST_ANY);
We sort of wrote this in parallel, the only difference in our
implementations is that I also had a negative test with LITEST_ANY,
LITEST_KEYS that would always fail.
Not sure it's that important to test the -1 case anyway...
it is, please send me a patch for that test. It doesn't matter that much
right now, but for the tablet interface we'll have a similar one like
libinput_device_tablet_has_button(). And since tablets/buttonsets can have
keys that are sent as keys and others that are sent as buttons there is some
chance of overlap. So having the test won't hurt now, but will be helpful in
the future.
Sent, but I foolishly forgot to --in-reply-to this thread.
I can't actually use LITEST_ANY, LITEST_KEYS for the devices to test
though, because the roccat mouse and the wheel only device don't have
LITEST_KEYS in their feature lists.
Is it a bug that the roccat mouse doesn't feature LITEST_KEYS? If it
is, it'll break the existing libinput_device_keyboard_has_key() test to
switch it.
Not sure what to think about wheel only. It doesn't actually generate
key events, so despite being labeled a keyboard by udev rule, it's not
really a source of keys... So I guess that makes sense.
thanks for the reviews
Cheers,
Peter
Reviewed-by: Derek Foreman der...@osg.samsung.com
return litest_run(argc, argv);
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] tests: Add negative test for libinput_device_keyboard_has_key()
On Thu, Apr 23, 2015 at 05:05:49PM -0500, Derek Foreman wrote:
Ensure we get a -1 return for non-keyboard devices.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
test/keyboard.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/keyboard.c b/test/keyboard.c
index a477cfb..e098dc0 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -309,6 +309,20 @@ START_TEST(keyboard_has_key)
}
END_TEST
+START_TEST(keyboard_keys_bad_device)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+
+ if (libinput_device_has_capability(device,
+ LIBINPUT_DEVICE_CAP_KEYBOARD))
+ return;
+
+ ck_assert_int_eq(libinput_device_keyboard_has_key(device, KEY_A),
+ -1);
shouldn't we be running through the whole key range here? at least up to
BTN_MISC and then again from KEY_OK.
otherwise we don't catch devices that have e.g. KEY_POWER, never set up the
capability but still send the event.
+}
+END_TEST
+
int
main(int argc, char **argv)
{
@@ -316,6 +330,7 @@ main(int argc, char **argv)
litest_add_no_device(keyboard:key counting,
keyboard_ignore_no_pressed_release);
litest_add_no_device(keyboard:key counting,
keyboard_key_auto_release);
litest_add(keyboard:keys, keyboard_has_key, LITEST_KEYS, LITEST_ANY);
+ litest_add(keyboard:keys bad device, keyboard_keys_bad_device,
LITEST_ANY, LITEST_ANY);
use keyboard:keys as suite name please, they don't need to be different
for each key. the suite name is for grouping (e.g. touchpad:scroll,
touchpad:tap)
Cheers,
Peter
return litest_run(argc, argv);
}
--
2.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
On Wed, 22 Apr 2015 08:38:22 -0700 Bill Spitzak spit...@gmail.com wrote: On 04/21/2015 11:34 PM, Pekka Paalanen wrote: I also think this discussion is going off-topic. You wanted to add annotations to the XML, so you could find out about enum and bitfield arguments, so let's keep to that. There is value in simplicity. Absolutely agree How about this: Auke's original patch is much more like what is wanted. Yeah, it mostly just lacked a clear explanation on what the new attributes mean. It seems Auke and Jeroen had quite different interpretations and goals. However, a remaining problem is that an interface cannot reference an enum defined for a different interface. You can reference objects defined by a different interface, right? I don't think this is any different. Objects work because you know they are represented by an id. For many languages the code generation does not depend on the details of the enumeration, it just needs to know it's name, so there is no need to parse the other file. And whether int or uint is in the api, but that information is already there. Sure, by the interface name. However, I assumed the new attribute would refer to an enum by it's short name, not a fully qualified name that includes the interface name. Allowing fully qualified names is another thing. Should we allow it? Is it good practice? Is it useful? How would the fully qualitified names look like? Even if it's not used for codegen, you need it for docgen if you want to be able to reference other interfaces' enums. Many interfaces may have same-named enums. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
On Wed, 22 Apr 2015 11:47:51 +0200 Auke Booij a...@tulcod.com wrote: On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote: I also think this discussion is going off-topic. You wanted to add annotations to the XML, so you could find out about enum and bitfield arguments, so let's keep to that. There is value in simplicity. How about this: Add three new, mutually exclusive attributes for arg tags: docenum=enumname Docenum would be for documentation linking only, and should not affect code generation. The effect would be in the documentation to add a link to the definition of the enumname enum. This attribute is applicable for both int and uint type args. enumeration=enumname Enumeration would be a doc link, but also specify that the enum enumname is a complete enumeration: no other values are legal. You can use this for code generation. You will rely on interface version negotiation to avoid unknown values in case you have an old definition of the interface and your opponent is using a new definition which added values. This attribute is applicable for both int and uint type args. bitfield=enumname Bitfield would be a doc link, but also specify that the values listed in enum enumanme can be orred together to form new legal values. Bits that are not settable by using the listed values must be zero. You rely on the interface versioning to avoid getting undefined bits set, just like enumeration relies for adding new values. This attribute is applicable only to uint type args. So, both enumeration and bitfield could be used for codegen, docenum would not. Docenum or nothing would be used for cases that do not fit as enumeration or bitfield, including cases where unknown values are always allowed but the interface specification defines what to do when encountering one (ignore, use as a literal value, ...). Wayland-scanner would generate the doclink references in header comments, and check that the referenced enum exists and the arg type. Two comments on this. 1. I do not think it is necessary to distinguish between docenum and enumeration. At least for me, I am not asking for any new guarantees with regards to completeness: sure, new constants may be added on the fly. All I want is semantic information: which (u)int refers to which enum? And this data would be provided by your docenum (which I would just call enum). Jeroen seemed to be wanting that. That's why it gets complicated. It also wasn't clear as your patch didn't have a good explanation on what the attributes really mean. Explaining them is the most important part of a patch, especially how it may affect codegen (or in this case, must not affect codegen). Completeness of enums is information that can be encoded in strongly typed languages, but I do not think such guarantees are necessary. Bindings should be able to deal with new constants not listed in the protocol. If we guarantee completeness of enums, I expect we will get all kinds of backwards compatibility issues. Nice to hear. 2. I would say the property of being a bitfield belongs to an enum, not to an argument: the type that is generated corresponds to an enum, not to an argument. And as such, the properties of this type should not depend on the argument's attributes. So I would say the bitfield attribute should go in the enum. Otherwise, what is meant if one argument uses an enum as a bitfield, and another argument uses the same enum as a regular enum? Okay. I agree that it should express that OR'ing together any number of values from the list should *at least* not be considered a protocol error. They may still be disregarded for other reasons, but passing OR'ed values in a bitfield should not break protocol, and this is the guarantee a bitfield flag should express (IMO). I'm not sure about that. The allowance to or things together was more related to the strict enumeration enforcement. Interfaces should be able to still say, that a certain combination is illegal and will lead to a protocol error. None of it will ever break protocol on the wire level, as it is all just uints. Given this and that they must not affect codegen, what are the remaining differences between enums and bitfields? Enum can be an int, but a bitfield cannot? Is it worth to have the distinction in the language at all? In the end, is the only really useful thing left the doc linking? It seems the main difference between your and Jeroen's requirements is that Jeroen wants strict guarantees so that codegen can generate the strictest APIs in his language. However, a remaining problem is that an interface cannot reference an enum defined for a different interface. That is a special case I don't know if we should support in this scheme, because it would require the depended-on XML file to be used during parsing, and we do not require that for
Re: [PATCH wayland] Add enum attribute to arg elements
On Thu, 23 Apr 2015 10:17:12 +0200 Auke Booij a...@tulcod.com wrote: On 23 April 2015 at 08:38, Pekka Paalanen ppaala...@gmail.com wrote: On Wed, 22 Apr 2015 11:47:51 +0200 Auke Booij a...@tulcod.com wrote: On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote: I also think this discussion is going off-topic. You wanted to add annotations to the XML, so you could find out about enum and bitfield arguments, so let's keep to that. There is value in simplicity. How about this: Add three new, mutually exclusive attributes for arg tags: docenum=enumname Docenum would be for documentation linking only, and should not affect code generation. The effect would be in the documentation to add a link to the definition of the enumname enum. This attribute is applicable for both int and uint type args. enumeration=enumname Enumeration would be a doc link, but also specify that the enum enumname is a complete enumeration: no other values are legal. You can use this for code generation. You will rely on interface version negotiation to avoid unknown values in case you have an old definition of the interface and your opponent is using a new definition which added values. This attribute is applicable for both int and uint type args. bitfield=enumname Bitfield would be a doc link, but also specify that the values listed in enum enumanme can be orred together to form new legal values. Bits that are not settable by using the listed values must be zero. You rely on the interface versioning to avoid getting undefined bits set, just like enumeration relies for adding new values. This attribute is applicable only to uint type args. So, both enumeration and bitfield could be used for codegen, docenum would not. Docenum or nothing would be used for cases that do not fit as enumeration or bitfield, including cases where unknown values are always allowed but the interface specification defines what to do when encountering one (ignore, use as a literal value, ...). Wayland-scanner would generate the doclink references in header comments, and check that the referenced enum exists and the arg type. Two comments on this. 1. I do not think it is necessary to distinguish between docenum and enumeration. At least for me, I am not asking for any new guarantees with regards to completeness: sure, new constants may be added on the fly. All I want is semantic information: which (u)int refers to which enum? And this data would be provided by your docenum (which I would just call enum). Jeroen seemed to be wanting that. That's why it gets complicated. I agree. Well, if there is support for Jeroen's ideas, I will add that to the scanner.c patch. I am not against them, but I would expect the guarantees to be broken by C code all the time, so there needs to be a solution for that. I'd rather not, or at least separate these two. We can add the doc attribute, and discuss the strictness later. Adding strictness constraints later should be as simple as adding more attributes. However, if strictness attributes affect codegen, it might be difficult to add them to existing enums, because it would change the API a code generator produces. That is a pretty strong reason to not change anything that affects codegen: you may be using an XML file that does not have these attributes, or you may be using a generator that does not handle these attributes. Third party XML files are a thing, you don't have control over everything. Version requirements on depended-on projects could be used to mitigate it, plus perhaps a switch to the generator to ignore the new attributes until your code ports to the strictly typed API. I agree that it should express that OR'ing together any number of values from the list should *at least* not be considered a protocol error. They may still be disregarded for other reasons, but passing OR'ed values in a bitfield should not break protocol, and this is the guarantee a bitfield flag should express (IMO). I'm not sure about that. The allowance to or things together was more related to the strict enumeration enforcement. Interfaces should be able to still say, that a certain combination is illegal and will lead to a protocol error. None of it will ever break protocol on the wire level, as it is all just uints. Given this and that they must not affect codegen, what are the remaining differences between enums and bitfields? Enum can be an int, but a bitfield cannot? Is it worth to have the distinction in the language at all? In the end, is the only really useful thing left the doc linking? Well, for one, there is a semantic difference, which in richly typed languages is not to be underestimated. Perhaps the requirement should be that: at least one (non-empty) combination of listed values
Re: [PATCH] ivi-shell: support surface screen shot of ivi_layout by using weston_surface_copy_content
On Tue, 21 Apr 2015 02:13:15 +0900 Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp wrote: The reason why the result is not output in the method is that it avoids to have dependency on CAIRO. If user want to output it to file, user shall link CAIRO on its controller. ivi_layout_surface_get_size is also supported here because user needs stride to call ivi_layout_surafce_dump. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp Reviewed-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- ivi-shell/ivi-layout-export.h | 12 ++ ivi-shell/ivi-layout.c| 55 ++- 2 files changed, 66 insertions(+), 1 deletion(-) Pushed: e12a186..c3fd624 master - master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Add enum attribute to arg elements
On 23 April 2015 at 08:38, Pekka Paalanen ppaala...@gmail.com wrote: On Wed, 22 Apr 2015 11:47:51 +0200 Auke Booij a...@tulcod.com wrote: On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote: I also think this discussion is going off-topic. You wanted to add annotations to the XML, so you could find out about enum and bitfield arguments, so let's keep to that. There is value in simplicity. How about this: Add three new, mutually exclusive attributes for arg tags: docenum=enumname Docenum would be for documentation linking only, and should not affect code generation. The effect would be in the documentation to add a link to the definition of the enumname enum. This attribute is applicable for both int and uint type args. enumeration=enumname Enumeration would be a doc link, but also specify that the enum enumname is a complete enumeration: no other values are legal. You can use this for code generation. You will rely on interface version negotiation to avoid unknown values in case you have an old definition of the interface and your opponent is using a new definition which added values. This attribute is applicable for both int and uint type args. bitfield=enumname Bitfield would be a doc link, but also specify that the values listed in enum enumanme can be orred together to form new legal values. Bits that are not settable by using the listed values must be zero. You rely on the interface versioning to avoid getting undefined bits set, just like enumeration relies for adding new values. This attribute is applicable only to uint type args. So, both enumeration and bitfield could be used for codegen, docenum would not. Docenum or nothing would be used for cases that do not fit as enumeration or bitfield, including cases where unknown values are always allowed but the interface specification defines what to do when encountering one (ignore, use as a literal value, ...). Wayland-scanner would generate the doclink references in header comments, and check that the referenced enum exists and the arg type. Two comments on this. 1. I do not think it is necessary to distinguish between docenum and enumeration. At least for me, I am not asking for any new guarantees with regards to completeness: sure, new constants may be added on the fly. All I want is semantic information: which (u)int refers to which enum? And this data would be provided by your docenum (which I would just call enum). Jeroen seemed to be wanting that. That's why it gets complicated. I agree. Well, if there is support for Jeroen's ideas, I will add that to the scanner.c patch. I am not against them, but I would expect the guarantees to be broken by C code all the time, so there needs to be a solution for that. I agree that it should express that OR'ing together any number of values from the list should *at least* not be considered a protocol error. They may still be disregarded for other reasons, but passing OR'ed values in a bitfield should not break protocol, and this is the guarantee a bitfield flag should express (IMO). I'm not sure about that. The allowance to or things together was more related to the strict enumeration enforcement. Interfaces should be able to still say, that a certain combination is illegal and will lead to a protocol error. None of it will ever break protocol on the wire level, as it is all just uints. Given this and that they must not affect codegen, what are the remaining differences between enums and bitfields? Enum can be an int, but a bitfield cannot? Is it worth to have the distinction in the language at all? In the end, is the only really useful thing left the doc linking? Well, for one, there is a semantic difference, which in richly typed languages is not to be underestimated. Perhaps the requirement should be that: at least one (non-empty) combination of listed values OR'ed together results in a new valid value (ie one not listed) This is a sort of sanity condition on being a bitfield: it does not require all combinations are valid, but it also distinguishes it from a regular enum. It seems the main difference between your and Jeroen's requirements is that Jeroen wants strict guarantees so that codegen can generate the strictest APIs in his language. I agree. Like I said, such guarantees are welcome, as long as the situation is also clear for C, so that we don't get any annoying incompatibilities due to misunderstandings between languages. At this point I am not asking for them. I fixed Bill's note on my sample patch, and will publish my intermediary work on my github [0] (probably this will be limited to just two commits, but you can subscribe if you want to). [0] https://github.com/tulcod/wayland/tree/enum-attribute ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
Re: [PATCH libinput v4 0/2] Fix Lenovo X230 series touchpad
On Thu, Apr 23, 2015 at 1:53 PM, Vasily Khoruzhick anars...@gmail.com wrote: Hi Benjamin, v4 is completely unusable. With slow motion cursor is _too_ slow, with faster it's too fast. First version was _much_ better. Even more: I'd say non-patched libinput behaves better than v4. Please commit v1 version. Regards, Vasily On Mon, Apr 20, 2015 at 9:29 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: Hi, This is a new attempt to fix the X230 series. This time, I tried to put some more scientific effort, and used gnuplot to try to understand what was happening and how we could catch the same acceleration at high speed than regular touchpads. The results are synthetized in this png: http://people.freedesktop.org/~tissoire/x230.png The red-ish lines are the ones plotted from the regular touchpad acceleration profile for different speed settings (-1.0, 0.0, 1.0). The black one is the one I submitted in the v1 of this series. You can see that the max speed is caught when the input speed is 5, which is not the common use case. So I tried to implement what I wanted to do the first time: - at low speed, slow down the cursor - at high speed ( 2), catch up with the other touchpads - find something acceptable in the middle Not having to use the generic linear pointer acceleration made things much easier to tune, and I ended up with the code in patch 1/2. If other users of the X230 find this acceptable, I propose that we merge this and then we try to tune it later. My believe is that unless we properly filter the incoming events, we won't be able to have a smooth solution. Nevertheless, I feel that these settings should be OK. Cheers, Benjamin Benjamin Tissoires (2): evdev: use a different filter for low resolution touchpad on the Lenovo X230 udev: add a custom udev rule for X230 touchpads doc/device-configuration-via-udev.dox |9 +++ src/evdev-mt-touchpad.c | 14 +-- src/evdev.c | 23 +++ src/evdev.h |7 + src/filter.c | 40 + src/filter.h |5 udev/90-libinput-model-quirks.rules | 14 +++ udev/Makefile.am |4 ++- 8 files changed, 112 insertions(+), 4 deletions(-) create mode 100644 udev/90-libinput-model-quirks.rules ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v4 0/2] Fix Lenovo X230 series touchpad
Hi Benjamin, v4 is completely unusable. With slow motion cursor is _too_ slow, with faster it's too fast. First version was _much_ better. Regards, Vasily On Mon, Apr 20, 2015 at 9:29 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: Hi, This is a new attempt to fix the X230 series. This time, I tried to put some more scientific effort, and used gnuplot to try to understand what was happening and how we could catch the same acceleration at high speed than regular touchpads. The results are synthetized in this png: http://people.freedesktop.org/~tissoire/x230.png The red-ish lines are the ones plotted from the regular touchpad acceleration profile for different speed settings (-1.0, 0.0, 1.0). The black one is the one I submitted in the v1 of this series. You can see that the max speed is caught when the input speed is 5, which is not the common use case. So I tried to implement what I wanted to do the first time: - at low speed, slow down the cursor - at high speed ( 2), catch up with the other touchpads - find something acceptable in the middle Not having to use the generic linear pointer acceleration made things much easier to tune, and I ended up with the code in patch 1/2. If other users of the X230 find this acceptable, I propose that we merge this and then we try to tune it later. My believe is that unless we properly filter the incoming events, we won't be able to have a smooth solution. Nevertheless, I feel that these settings should be OK. Cheers, Benjamin Benjamin Tissoires (2): evdev: use a different filter for low resolution touchpad on the Lenovo X230 udev: add a custom udev rule for X230 touchpads doc/device-configuration-via-udev.dox |9 +++ src/evdev-mt-touchpad.c | 14 +-- src/evdev.c | 23 +++ src/evdev.h |7 + src/filter.c | 40 + src/filter.h |5 udev/90-libinput-model-quirks.rules | 14 +++ udev/Makefile.am |4 ++- 8 files changed, 112 insertions(+), 4 deletions(-) create mode 100644 udev/90-libinput-model-quirks.rules ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: add support for LIBINPUT_MODEL_* udev tags
Hi,
On 23-04-15 04:07, Peter Hutterer wrote:
Some devices need specific configuration or different defaults.
Push that into udev rules and a hwdb file, that's where detection is the
easiest. The LIBINPUT_MODEL_ prefix is used to determine some type of device
model. Note that this property is a private API and subject to change at
any time without notice.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
A few more changes than expected, so sending this out again for another
set of eyes on it. This is the infrastructure to tag things with
LIBINPUT_MODEL_* udev properties, it's not in use by anything just yet.
doc/device-configuration-via-udev.dox | 15 +++
src/evdev.c | 22 ++
src/evdev.h | 6 ++
udev/90-libinput-model-quirks.hwdb| 16
udev/90-libinput-model-quirks.rules | 25 +
udev/Makefile.am | 8 +++-
6 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 udev/90-libinput-model-quirks.hwdb
create mode 100644 udev/90-libinput-model-quirks.rules
diff --git a/doc/device-configuration-via-udev.dox
b/doc/device-configuration-via-udev.dox
index c22aafa..e38b93f 100644
--- a/doc/device-configuration-via-udev.dox
+++ b/doc/device-configuration-via-udev.dox
@@ -63,6 +63,9 @@ libinput_pointer_get_axis_source() for details.
dtPOINTINGSTICK_CONST_ACCEL/dt
ddA constant (linear) acceleration factor to apply to pointingstick deltas
to normalize them.
+dtLIBINPUT_MODEL_*/dt
+ddbThis prefix is reserved as private API, do not use./b. See @ref
+model_specific_configuration for details.
/dd
/dl
@@ -98,4 +101,16 @@ ACTION==add|change, KERNEL==event[0-9]*,
ENV{ID_VENDOR_ID}==012a, \
ENV{ID_MODEL_ID}==034b, ENV{ID_INPUT_TOUCHPAD}=, ENV{ID_INPUT_TABLET}=1
@endcode
+@section model_specific_configuration Model-specific configuration
+
+libinput reserves the property prefix bLIBINPUT_MODEL_/b for
+model-specific configuration. bThis prefix is reserved as private API, do
+not use./b
+
+The effect of this property may be to enable or disable certain
+features on a specific device or set of devices, to change configuration
+defaults or any other reason. The effects of setting this property, the
+format of the property and the value of the property are subject to change
+at any time.
+
*/
diff --git a/src/evdev.c b/src/evdev.c
index 964b3ba..e3bba93 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1422,6 +1422,27 @@ evdev_read_dpi_prop(struct evdev_device *device)
return dpi;
}
+static inline enum evdev_device_model
+evdev_read_model(struct evdev_device *device)
+{
+ const struct model_map {
+ const char *property;
+ enum evdev_device_model model;
+ } model_map[] = {
+ { NULL, EVDEV_MODEL_DEFAULT },
+ };
+ const struct model_map *m = model_map;
+
+ while (m-property) {
+ if (!!udev_device_get_property_value(device-udev_device,
+m-property))
+ break;
+ m++;
+ }
+
+ return m-model;
+}
+
/* Return 1 if the given resolutions have been set, or 0 otherwise */
inline int
evdev_fix_abs_resolution(struct evdev_device *device,
@@ -1950,6 +1971,7 @@ evdev_device_create(struct libinput_seat *seat,
device-scroll.wheel_click_angle =
evdev_read_wheel_click_prop(device);
device-dpi = evdev_read_dpi_prop(device);
+ device-model = evdev_read_model(device);
/* at most 5 SYN_DROPPED log-messages per 30s */
ratelimit_init(device-syn_drop_limit, 30ULL * 1000, 5);
diff --git a/src/evdev.h b/src/evdev.h
index 9f24453..edd4011 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -93,6 +93,10 @@ enum evdev_middlebutton_event {
MIDDLEBUTTON_EVENT_ALL_UP,
};
+enum evdev_device_model {
+ EVDEV_MODEL_DEFAULT,
+};
+
struct mt_slot {
int32_t seat_slot;
struct device_coords point;
@@ -202,6 +206,8 @@ struct evdev_device {
int dpi; /* HW resolution */
struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
+
+ enum evdev_device_model model;
};
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
diff --git a/udev/90-libinput-model-quirks.hwdb
b/udev/90-libinput-model-quirks.hwdb
new file mode 100644
index 000..02bb8f9
--- /dev/null
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -0,0 +1,16 @@
+# Do not edit this file, it will be overwritten on update
+#
+# This file contains hwdb matches for libinput model-specific quirks.
+# The contents of this file are a contract between libinput, udev rules and
+# the hwdb.
+# IT IS NOT A STABLE API AND SUBJECT TO CHANGE AT ANY TIME
+
+# The lookup keys are composed in:
+#
Re: [PATCH libinput] Add libinput_device_keyboard_has_key()
On Thu, Apr 23, 2015 at 05:15:01PM -0500, Derek Foreman wrote:
On 22/04/15 07:05 PM, Peter Hutterer wrote:
On Wed, Apr 22, 2015 at 08:45:21AM -0500, Derek Foreman wrote:
On 21/04/15 11:44 PM, Peter Hutterer wrote:
Similar to libinput_device_pointer_has_button(), this function returns
whether
a given device has a specific keycode.
This enables a caller to determine if the device is really a keyboard
(check
for KEY_A-KEY_Z) or just a media key device (check for KEY_PLAY or
somesuch),
depending on the context required.
Cool, thanks. :)
Trivial comments below.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Had a deja-vu implementing this, I thought this already existed.
src/evdev.c | 9 +
src/evdev.h | 3 +++
src/libinput.c | 6 ++
src/libinput.h | 16
src/libinput.sym | 5 +
test/keyboard.c | 20
6 files changed, 59 insertions(+)
[...]
diff --git a/test/keyboard.c b/test/keyboard.c
index cb7ad52..a477cfb 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -290,12 +290,32 @@ START_TEST(keyboard_key_auto_release)
}
END_TEST
+START_TEST(keyboard_has_key)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput_device *device = dev-libinput_device;
+ unsigned int code;
+ int evdev_has, libinput_has;
+
+ ck_assert(libinput_device_has_capability(
+ device,
+ LIBINPUT_DEVICE_CAP_KEYBOARD));
+
+ for (code = 0; code KEY_CNT; code++) {
+ evdev_has = libevdev_has_event_code(dev-evdev, EV_KEY, code);
+ libinput_has = libinput_device_keyboard_has_key(device, code);
+ ck_assert_int_eq(evdev_has, libinput_has);
+ }
+}
+END_TEST
+
int
main(int argc, char **argv)
{
litest_add_no_device(keyboard:seat key count,
keyboard_seat_key_count);
litest_add_no_device(keyboard:key counting,
keyboard_ignore_no_pressed_release);
litest_add_no_device(keyboard:key counting,
keyboard_key_auto_release);
+ litest_add(keyboard:keys, keyboard_has_key, LITEST_KEYS, LITEST_ANY);
We sort of wrote this in parallel, the only difference in our
implementations is that I also had a negative test with LITEST_ANY,
LITEST_KEYS that would always fail.
Not sure it's that important to test the -1 case anyway...
it is, please send me a patch for that test. It doesn't matter that much
right now, but for the tablet interface we'll have a similar one like
libinput_device_tablet_has_button(). And since tablets/buttonsets can have
keys that are sent as keys and others that are sent as buttons there is some
chance of overlap. So having the test won't hurt now, but will be helpful in
the future.
Sent, but I foolishly forgot to --in-reply-to this thread.
I can't actually use LITEST_ANY, LITEST_KEYS for the devices to test
though, because the roccat mouse and the wheel only device don't have
LITEST_KEYS in their feature lists.
Is it a bug that the roccat mouse doesn't feature LITEST_KEYS? If it
is, it'll break the existing libinput_device_keyboard_has_key() test to
switch it.
hmm, the test still passes here when I enable it (that's the existing one,
not your new one). What fails for you?
I think we should set it, at least until we have separate tests for the
various multimedia keys.
Not sure what to think about wheel only. It doesn't actually generate
key events, so despite being labeled a keyboard by udev rule, it's not
really a source of keys... So I guess that makes sense.
that's a recent addition to input_id. thing is that if we only have a
REL_WHEEL or REL_HWEEL none of the other tags are appropriate, so
ID_INPUT_KEYBOARD is somewhat of a fallback here.
I think we can ignore that.
Cheers,
Peter
thanks for the reviews
Cheers,
Peter
Reviewed-by: Derek Foreman der...@osg.samsung.com
return litest_run(argc, argv);
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] touchpad: allow BTN_LEFT in clickfinger mode without touches
On the Logitech T650 it's quite easy to trigger a click without touching the
surface. For software buttons we discard those clicks because we can't tell
where the finger is to decide on left vs right click.
It takes effort to trigger a click with two fingers without triggering a touch
though, so in clickfinger mode post a click without toucheas as single-finger
click.
https://bugs.freedesktop.org/show_bug.cgi?id=90150
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 6 --
test/touchpad.c | 30 ++
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index c907ecc..7f60a53 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -804,6 +804,7 @@ tp_notify_clickpadbutton(struct tp_dispatch *tp,
if (tp-buttons.click_method ==
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER
state == LIBINPUT_BUTTON_STATE_PRESSED) {
switch (tp-nfingers_down) {
+ case 0:
case 1: button = BTN_LEFT; break;
case 2: button = BTN_RIGHT; break;
case 3: button = BTN_MIDDLE; break;
@@ -865,7 +866,8 @@ tp_post_clickpadbutton_buttons(struct tp_dispatch *tp,
uint64_t time)
}
}
- if (area == 0) {
+ if (area == 0
+ tp-buttons.click_method !=
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER) {
/* No touches, wait for a touch before processing */
tp-buttons.click_pending = true;
return 0;
@@ -877,7 +879,7 @@ tp_post_clickpadbutton_buttons(struct tp_dispatch *tp,
uint64_t time)
button = evdev_to_left_handed(tp-device, BTN_RIGHT);
else if (area LEFT)
button = evdev_to_left_handed(tp-device, BTN_LEFT);
- else /* main area is always BTN_LEFT */
+ else /* main or no area (for clickfinger) is always BTN_LEFT */
button = BTN_LEFT;
tp-buttons.active = button;
diff --git a/test/touchpad.c b/test/touchpad.c
index c04ef11..db981dc 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1506,6 +1506,32 @@ START_TEST(touchpad_1fg_clickfinger)
}
END_TEST
+START_TEST(touchpad_1fg_clickfinger_no_touch)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ enum libinput_config_status status;
+
+ status = libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER);
+ ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
+
+ litest_drain_events(li);
+
+ litest_event(dev, EV_KEY, BTN_LEFT, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_event(dev, EV_KEY, BTN_LEFT, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ libinput_dispatch(li);
+
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_PRESSED);
+ litest_assert_button_event(li, BTN_LEFT,
+ LIBINPUT_BUTTON_STATE_RELEASED);
+}
+END_TEST
+
START_TEST(touchpad_2fg_clickfinger)
{
struct litest_device *dev = litest_current_device();
@@ -1785,6 +1811,9 @@ START_TEST(clickpad_btn_left)
struct litest_device *dev = litest_current_device();
struct libinput *li = dev-libinput;
+ libinput_device_config_click_set_method(dev-libinput_device,
+
LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS);
+
litest_drain_events(li);
/* A clickpad always needs a finger down to tell where the
@@ -4119,6 +4148,7 @@ int main(int argc, char **argv) {
litest_add(touchpad:tap, clickpad_2fg_tap_click, LITEST_CLICKPAD,
LITEST_SINGLE_TOUCH|LITEST_APPLE_CLICKPAD);
litest_add(touchpad:clickfinger, touchpad_1fg_clickfinger,
LITEST_CLICKPAD, LITEST_ANY);
+ litest_add(touchpad:clickfinger, touchpad_1fg_clickfinger_no_touch,
LITEST_CLICKPAD, LITEST_ANY);
litest_add(touchpad:clickfinger, touchpad_2fg_clickfinger,
LITEST_CLICKPAD, LITEST_ANY);
litest_add(touchpad:clickfinger, touchpad_clickfinger_to_area_method,
LITEST_CLICKPAD, LITEST_ANY);
litest_add(touchpad:clickfinger,
--
2.3.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
