RE:(2) Question about Linux MT Protocol B type

[강정현]

Dear Mr. Hutterer.
 
Thanks you for your reply.
And I have another question about this, so I hope you reply about this question.
 
Following my second case, libinput reports below events. (used evtest and libinput debug-events)




Event: time 1420073073.110197, type 3 (Absolute), code 57 (MT Tracking ID), value 22Event: time 1420073073.110197, type 1 (Key), code 330 (Touch), value 1Event: time 1420073073.110197, type 3 (Absolute), code 53 (MT Position X), value 176Event: time 1420073073.110197, type 3 (Absolute), code 54 (MT Position Y), value 1027Event: time 1420073073.143950, -- Report Sync Event: time 1420073073.165862, type 3 (Absolute), code 57 (MT Tracking ID), value -1Event: time 1420073073.165862, type 1 (Key), code 330 (Touch), value 0Event: time 1420073073.165862, type 3 (Absolute), code 47 (MT Slot), value 1Event: time 1420073073.165862, type 3 (Absolute), code 57 (MT Tracking ID), value 23Event: time 1420073073.165862, type 1 (Key), code 330 (Touch), value 1Event: time 1420073073.165862, type 3 (Absolute), code 53 (MT Position X), value 628Event: time 1420073073.165862, type 3 (Absolute), code 54 (MT Position Y), value 1099Event: time 1420073073.177031, -- Report Sync Event: time 1420073073.210082, type 3 (Absolute), code 57 (MT Tracking ID), value -1Event: time 1420073073.210082, type 1 (Key), code 330 (Touch), value 0Event: time 1420073073.210082, -- Report Sync 
 




 event2   TOUCH_DOWN   +39.022s 0 (0) 24.44/80.23 (176.00/1027.00mm) event2   TOUCH_FRAME  +39.022s  event2   TOUCH_UP +39.078s  event2   TOUCH_DOWN   +39.078s 1 (0) 87.22/85.86 (628.00/1099.00mm) event2   TOUCH_FRAME  +39.078s  event2   TOUCH_UP +39.122s  event2   TOUCH_FRAME  +39.122s
 
So I looks like 1st finger down -> 1st finger up -> 2nd finger down -> 2nd finger up
I interpret it: 2nd finger down can come first than 1st finger, after all fingers are released.
 
I have thought that first touch down's index is always 0.
But following in this case, second or third touch down can come fater than first touch down.
 
So I ask it to you that second finger down came fisrt situation is normal situation or not..
I'll waiting for your reply.
If you reply about this, it helps me a lot.
 
Thanks and regards,
JeongHyun Kang.
 
- Original Message -
Sender : Peter Hutterer 
Date : 2020-05-22 12:32 (GMT+9)
Title : Re: Question about Linux MT Protocol B type
 On Thu, May 21, 2020 at 07:42:33PM +0900, 강정현 wrote:
> Dear all,
> 
> I have an one question about Linux MT Protocol B type.
> 
> Asume that press touch screen using first finger.
> 
> And release fisrt finger and press second finger toghether.
> 
>  
> 
> In that case, which procotol is correct?
> 
> ┌───┐
> │ ABS_MT_SLOT 0 │
> │   │
> │ ABS_MT_TRACKING_ID 1  │
> │   │
> │ ABS_MT_POSITION_X 10  │
> │   │
> │ ABS_MT_POSITION_Y 5   │
> │   │
> │ ABS_MT_SYNC <-- first finger press│
> └───┘

There's no such thing as ABS_MT_SYNC, use SYN_REPORT here.

> first case
> 
> ┌───┐
> │ ABS_MT_TRACKING_ID -1 │
> │   │
> │ ABS_MT_TRACKING_ID 2  │
> │

Question about Linux MT Protocol B type

[강정현]

Dear all,
I have an one question about Linux MT Protocol B type.
 
Asume that press touch screen using first finger.
And release fisrt finger and press second finger toghether.
 
In that case, which procotol is correct?
 




 ABS_MT_SLOT 0
 ABS_MT_TRACKING_ID 1
 ABS_MT_POSITION_X 10
 ABS_MT_POSITION_Y 5
 ABS_MT_SYNC <-- first finger press
 
first case




 ABS_MT_TRACKING_ID -1
 ABS_MT_TRACKING_ID 2
 ABS_MT_POSITION_X 15
 ABS_MT_POSITION_Y 10
 ABS_MT_SYNC <-- first finger release and first finger press is generated
 
second case




 ABS_MT_TRACKING_ID -1
 ABS_MT_SLOT 1
 ABS_MT_TRACKING_ID 2
 ABS_MT_POSITION_X 15
 ABS_MT_POSITION_Y 10
 ABS_MT_SYNC <-- first finger release and second finger press is generated
 
I think first case is correct, but sometimes second case procotol is generated.
I think second case event flow is like below:
first finger press -> first finger release -> (all finger released) -> second finger press
So, in this case said, second finger came first after all finger is released..
 
So I want to know which case is correct following Linux MT Protocol B type.
 
Someone who help me?
I'll waiting your opinions,
Thanks and regards,
JeongHyun Kang.
 
 
  
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Which package install locale files for xkb in wayland system?

[강정현]

Dear all.
 
I have known that locale data (for libxkbcommon) is exist in /usr/share/X11/locale/ normally.
And that is provided in libX11.
(refer libxkbcommon's documentation)




Dataset
libxkbcommon does not distribute a keymap dataset itself, other than for testing purposes. The most common dataset is xkeyboard-config, which is used by all current distributions for their X11 XKB data. More information on xkeyboard-config is available here: https://www.freedesktop.org/wiki/Software/XKeyboardConfig
The dataset for Compose is distributed in libX11, as part of the X locale data.
 
 
But libX11 is Xorg's library, and I cannot find locale data in wayland system.
Which package provides locale data?
 
Thanks and regards.
JeongHyun Kang. 
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[libinput] How can I prevent duplicated device?

[강정현]

Hello, guys.

I have a one question about the libinput API.
I want to share your opinions about duplicated device added events via udev.

Suppose to duplicated device add events(about a same device) are occurred.
Currently libinput opens two fd about a same event node.
So that I have a question that this process is right or a bug.

I thought several ways why you doesn't process this duplicated device added
events.

First, duplicated device add events are abnormal events so that
we do not concerned about this situation.

But sometimes we need to prevent these abnormal situation.
If it is valid to prevent duplicated device add events, which points is
good to add code.

First method is to use open_restrict interface.
It means that the libinput allow duplicated device add events and 
if user want to prevent it, do that in open_restrict interface.

But I regard as a burden to do that in the open_restrict(),
if it is right policy to prevent duplicated device add events.
So I added prevent code in the evdev_device_create() function.
Please refer attached patch file.(I copied this code below of email)

Please let me know your opinions about duplicated device add events.
I'll waiting your opinions and it is very helpful to me.

Thanks and regards,
JengHyun Kang.

>From 38e6005d01035f535e79207c856f4b4c80cb788b Mon Sep 17 00:00:00 2001
From: JengHyun Kang 
Date: Tue, 23 Aug 2016 14:18:06 +0900
Subject: [PATCH] evdev: Do not open the already opened device

---
 src/evdev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index f798e8e..35e3cec 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2529,6 +2529,16 @@ evdev_device_create(struct libinput_seat *seat,
int fd;
int unhandled_device = 0;
const char *devnode = udev_device_get_devnode(udev_device);
+   struct libinput_device *dev;
+
+   list_for_each(dev, >devices_list, link) {
+   struct evdev_device *d = (struct evdev_device*)dev;
+   if (streq(devnode, udev_device_get_devnode(d-
>udev_device))) {
+   log_info(libinput,
+   "%s device is already opened\n", d-
>devname);
+   goto err;
+   }
+   }
 
/* Use non-blocking mode so that we can loop on read on
 * evdev_device_data() until all events on the fd are
-- 
1.9.1


0001-evdev-Do-not-open-the-already-opened-device.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[libinput] How I get to device's bustype using libinput API?

[강정현]

Hello, guys.

I have a one question about the libinput API.

I want to get device's bustype to know how this device is connected.
But there is no thie API and that API is supported only in libevdev.

But other APIs to get device information are supported(abstracted) in
libinput.
libevdev_get_id_product() -> libinput_device_get_id_product()
libevdev_get_id_vendor()  ->  libinput_device_get_id_vendor()

I don't know why libevdev_get_id_bustype() is not abstracted.
There is a another way to get bustype?
If it is exist, please let me know.

But if it isn't exist how about add a new API to get bustype like my patch
file?
I attached my patch file and if it looks good, I update to it using git.

My patch file like below.

Please give me opinions.
Thanks and regards,
JengHyun Kang.


===

>From 0fb1727621932a24ea33795c1da3988f134974df Mon Sep 17 00:00:00 2001
From: JengHyun Kang 
Date: Tue, 2 Aug 2016 12:27:21 +0900
Subject: [PATCH] evdev: Support a API to provide bustype information

There are APIs to get device's specific information,
such as libinput_device_get_id_product() and
libinput_device_get_id_vendor().
These APIs abstract libevdev APIs,
such as libevdev_get_id_product() and
libevdev_get_id_vendor().
But there is no abstraction API to get bustype.

Bustype sometimes provides proper information to know
how this device is connected.
So I added this API to get device's bustype.
---
 src/evdev.c  |  6 ++
 src/evdev.h  |  3 +++
 src/libinput.c   |  6 ++
 src/libinput.h   | 11 +++
 src/libinput.sym |  1 +
 5 files changed, 27 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index 375d0a5..0378401 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2560,6 +2560,12 @@ evdev_device_get_id_vendor(struct evdev_device
*device)
return libevdev_get_id_vendor(device->evdev);
 }
 
+unsigned int
+evdev_device_get_id_bustype(struct evdev_device *device)
+{
+   return libevdev_get_id_bustype(device->evdev);
+}
+
 struct udev_device *
 evdev_device_get_udev_device(struct evdev_device *device)
 {
diff --git a/src/evdev.h b/src/evdev.h
index f73b88b..ec389c1 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -356,6 +356,9 @@ evdev_device_get_id_product(struct evdev_device
*device);
 unsigned int
 evdev_device_get_id_vendor(struct evdev_device *device);
 
+unsigned int
+evdev_device_get_id_bustype(struct evdev_device *device);
+
 struct udev_device *
 evdev_device_get_udev_device(struct evdev_device *device);
 
diff --git a/src/libinput.c b/src/libinput.c
index a8240bd..610a01b 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -2775,6 +2775,12 @@ libinput_device_get_id_vendor(struct libinput_device
*device)
return evdev_device_get_id_vendor((struct evdev_device *) device);
 }
 
+LIBINPUT_EXPORT unsigned int
+libinput_device_get_id_bustype(struct libinput_device *device)
+{
+   return evdev_device_get_id_bustype((struct evdev_device *) device);
+}
+
 LIBINPUT_EXPORT const char *
 libinput_device_get_output_name(struct libinput_device *device)
 {
diff --git a/src/libinput.h b/src/libinput.h
index 83e58b6..fb94bac 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -3355,6 +3355,17 @@ libinput_device_get_id_vendor(struct libinput_device
*device);
 /**
  * @ingroup device
  *
+ * Get the bustype ID for this device.
+ *
+ * @param device A previously obtained device
+ * @return The bustype ID of this device
+ */
+unsigned int
+libinput_device_get_id_bustype(struct libinput_device *device);
+
+/**
+ * @ingroup device
+ *
  * A device may be mapped to a single output, or all available outputs. If
a
  * device is mapped to a single output only, a relative device may not move
  * beyond the boundaries of this output. An absolute device has its input
diff --git a/src/libinput.sym b/src/libinput.sym
index cb3f2b8..faf4ce0 100644
--- a/src/libinput.sym
+++ b/src/libinput.sym
@@ -42,6 +42,7 @@ global:
libinput_device_get_device_group;
libinput_device_get_id_product;
libinput_device_get_id_vendor;
+   libinput_device_get_id_bustype;
libinput_device_get_name;
libinput_device_get_output_name;
libinput_device_get_seat;
-- 
1.9.1


===



0001-evdev-Support-a-API-to-provide-bustype-information.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH] wayland-server: Add APIs to get some structure's value

[강정현]

Dear, Mr. Pekka Paalanen.

Thanks you for your rapid reply and
I understand what you mean.

Yes, I just want to make like weston-info.
But I want to insert extra information than weston-info.

Weston-info just print interface's name/version/id about user defined
interface.
So I can't print requests and events supported by interfaces.
And weston-info had difficult to query derived interfaces.
(I'm not sure that this is right expression.)
wl_seat and wl_keyboard/wl_pointer/wl_touch is similar to derived interface.

We could know how to get wl_keyboard because this is a base interface
supported in wayland.
So weston-info wait wl_keyboard using roundtrip.
But the debug tool like weston-info did not know,
how many derived interfaces were supported in this system.
So it did not print all of interfaces.
Because of this issue, I approach server side: global_list.

You said that "it is just a database generated from the XML files"
Yes, that is absolutely right.
I want to make debug tool like weston-info but give more information.
To give comfortable way to get information about wayland server and
protocol.

Can I give to you one more question?
Take weston-info to base, can I solve those problems?
 1st, get requests/events information(such as name)
 2nd, get whole of derived interfaces if I do not know that interface.

If it is not, and it is better method that get these information from XML,
(like you refer to prior email)
I will try that way.

Anyway thank you for your reply and attention.
It is helpful to me, so I appreciate these reply to you.

Thanks and regards,
JengHyun Kang.


> -Original Message-
> From: Pekka Paalanen [mailto:ppaala...@gmail.com]
> Sent: Wednesday, June 22, 2016 10:47 PM
> To: __
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH] wayland-server: Add APIs to get some structure's
> value
> 
> On Wed, 22 Jun 2016 19:45:15 +0900
> __  wrote:
> 
> > Dear, Mr. Pekka Paalanen.
> >
> > Thank you for your reply and opinion.
> > I have checked Mr. Giulio's patch:
> > https://patchwork.freedesktop.org/series/4181/
> > But unfortunately my patch was little different with Mr. Giulio's.
> >
> > His patch is to watch interfaces binded such clients.
> > So He added wl_resource_get_interface() function to refer interface
> > from resource.
> > But My patch's purpose is that print which interface is supported in
> > this server and which requests and events are supported current
> > interface.
> 
> Hi,
> 
> for that, you need none of what you posted.
> 
> Just make a normal client, create a wl_registry, and you will see what is
> *actually supported* by the server. You cannot even get that from the
> functions you added, because you are not taking into account the interface
> versions advertised by the server.
> 
> A server does not need to support the highest interface version that it
> has the descriptions for.
> 
> >
> > But if he has plan to expand "GammaRay"'s function, my patch can
> > support that.
> > Because I add this APIs to support debugging.
> >
> > I explain to my purpose to this patch.
> > So please give me more opinions.
> >
> > I want to see all of interfaces and requests/events names supported
> > current server.
> >
> > Ex> command in console: $print_supported_layout
> >  [1] wl_compositor
> >  -- Request List --
> > 0) create_surface
> > 1) create_region
> >  -- Event List --
> >
> >  [2] wl_subcompositor
> >  -- Request List --
> > 0) destroy
> > 1) get_subsurface
> >  -- Event List --
> >
> > Each server has different configuration, so that they could have
> > different about supported interface.
> 
> As I said, you get all the runtime information you need from a wl_registry
> as a normal client, and the rest you get from the protocol XML
> descriptions that are installed in the system, also extensions, not just
> Wayland core.
> 
> Try 'weston-info', works on any Wayland server.
> 
> > Because this could show not only wayland's basic protocol but also
> > extra protocol which is user defined.
> 
> Ok, so you want information from server supported extensions for which you
> do not have the XML files for. This is getting strange.
> 
> Is this for reverse-engineering?
> 
> > And it provide more convenience to client developer.
> 
> This I disagree. A client developer will always need the corresponding
> protocol XML description to be able to use it. You need to generate the
> programming language bindings from XML.
> 
> > The client developer can watch all of interface and requests/events
> easily.
> > (Yes, I know that to watch xml file is more easier to expert.)
> 
> You can also look at what wayland-scanner generates from the XML, and you
> can push that through Doxygen. Then you will have all of nice layout,
> documentation, and C API.
> 
> I would very strongly suggest writing a better document generator if
> reading XML or what we generate 

RE: [PATCH] wayland-server: Add APIs to get some structure's value

[강정현]

Dear, Mr. Pekka Paalanen.

Thank you for your reply and opinion.
I have checked Mr. Giulio's patch:
https://patchwork.freedesktop.org/series/4181/
But unfortunately my patch was little different with Mr. Giulio's.

His patch is to watch interfaces binded such clients.
So He added wl_resource_get_interface() function to refer interface from
resource.
But My patch's purpose is that print which interface is supported in this
server and
which requests and events are supported current interface.

But if he has plan to expand "GammaRay"'s function,
my patch can support that.
Because I add this APIs to support debugging.

I explain to my purpose to this patch.
So please give me more opinions.

I want to see all of interfaces and requests/events names supported current
server.

Ex> command in console: $print_supported_layout
 [1] wl_compositor
 -- Request List --
0) create_surface
1) create_region
 -- Event List --

 [2] wl_subcompositor
 -- Request List --
0) destroy
1) get_subsurface
 -- Event List --

Each server has different configuration,
so that they could have different about supported interface.
Because this could show not only wayland's basic protocol
but also extra protocol which is user defined.

And it provide more convenience to client developer.
The client developer can watch all of interface and requests/events easily.
(Yes, I know that to watch xml file is more easier to expert.)

This patch is not related to make new functions, fix bugs.
Just to make easier to debug.
Watch server's global list more easier.

I don't know this is enough explain why I want to added these APIs.

Have you give me more opinions or tips about this.
I'm ready to listen your opinions.
If you feel my purpose is reasonable I'll add more specific doc to each
APIs.

Thanks and regards,
JengHyun Kang.


> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
> On Behalf Of Pekka Paalanen
> Sent: Tuesday, June 21, 2016 5:02 PM
> To: JengHyun Kang
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH] wayland-server: Add APIs to get some structure's
> value
> 
> On Tue, 21 Jun 2016 13:45:16 +0900
> JengHyun Kang  wrote:
> 
> > This patch's purpose is getting global interface information
> > registerred in the server.
> > If global is created (used wl_global_create()), information are saved
> > in global_list.
> > But almost structures used in wayland is defined statically.
> > So it is hard to get structure's values in server side.
> >
> > Added following APIs.
> >   - wl_display_get_global_list()
> >   - wl_global_get_interface()
> >   - wl_interface_get_name()
> >   - wl_interface_get_method_count()
> >   - wl_interface_get_methods()
> >   - wl_interface_get_event_count()
> >   - wl_interface_get_events()
> >   - wl_message_get_name()
> >   - wl_global_list_get_global()
> >
> > You can get interface information to combine added APIs.
> > (Such as interface's name and events/requests name)
> >
> > 1st, you can get wl_list:global_list to use
wl_display_get_global_list().
> > 2nd, you can get length of wl_list to use wl_list_length() and
> >  wl_global to use wl_global_list_get_global().
> >  wl_global is saved in list, so you need index to get wl_global.
> > 3rd, you can get wl_interface to use wl_global_get_interface().
> > 4th, in wl_interface structure, there are so many information about
> >  interface name and events/requests information.
> >  so you can get information to use wl_interface_get_name(),
> >  wl_interface_get_method_count(), wl_interface_get_method(),
> >  wl_interface_get_event_count(), wl_interface_get_event().
> 
> Hi,
> 
> your commit message forgot to explain the one most important thing:
> 
> Why?
> 
> Also, please see https://patchwork.freedesktop.org/series/4181/ which is
> already reviewed and seems to overlap with yours. Giulio has demonstrated
> the use case for all the API he is adding with a single
> screenshot:
> https://i.imgur.com/ihW3d88.jpg
> 
> and also roughly explaining how "GammaRay" hooks up to a compositor.
> 
> It would be nice if you reviewed Giulio's series, checked how it matches
> your needs, and then explain what you are still missing and why.
> Personally I am in favour of Giulio's series and no-one has yet disagreed
> with it, so I think it has good chances of getting merged once polished.
> 
> 
> Thanks,
> pq
> 
> > ---
> >  src/wayland-server.c | 63
> > 
> >  src/wayland-server.h | 27 ++
> >  2 files changed, 90 insertions(+)
> >
> > diff --git a/src/wayland-server.c b/src/wayland-server.c index
> > 19aa2e8..ac5c2e5 100644
> > --- a/src/wayland-server.c
> > +++ b/src/wayland-server.c
> > @@ -997,6 +997,63 @@ wl_global_destroy(struct wl_global *global)
> > free(global);
> >  }
> >
> > +WL_EXPORT const struct 

[libinput] How I get to scroll.wheel_click_angle value using libinput?

[강정현]

Hello, guys.

When I check mouse wheel events using libinput,
I found that this wheel value was always converted by libinput.
Like this: wheel_degrees.y = -1 * e->value * device-
>scroll.wheel_click_angle.
In function evdev_process_relative().

That value is set using udev property named "MOUSE_WHEEL_CLICK_ANGLE".
But if that value is not exist, set default
value(DEFAULT_WHEEL_CLICK_ANGLE).

In that case, I move wheel to just one, kernel send wheel event that value
is 1,
and libinput changed it to 15(this is currently default value).

This is my concerned point. I just want to know mouse wheel's real move,
not converted value.
So I found how to get that value(scroll.wheel_click_angle) for revert value
to 1(like via kernel)
But currently libinput_device_config_scroll_* API's doesn't support this.

How can I get this value?
Or how about make a new API like
libinput_device_config_scroll_get_wheel_click_angle()?
If you this make sense, I will upload a commit to add a new API.

Please give me your opinions.
Thanks and regards,
JengHyun Kang.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[libinput] How I get extra touch events using libinput?

[강정현]

Hello, guys.
I have a query regarding linux MT protocol event handling in libinput side.
I wanted to get the extra events such as ABS_MT_TOUCH_MAJOR,
ABS_MT_PRESSURE as an event of libinput,
but I found that libinput doesn't handle those events.

Thus I'd like to know whether there is any plan regarding ABS_MT_XXX event
handling in libinput side.
If there are no plan to support those events, how can I handling those
events?

Please kindly answer for my query.

Thanks and regards,
JengHyun Kang.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [libinput] How I get extra touch events using libinput?

[강정현]

Dear Peter and guys,

thank you for your information about Andreas Pokorny's patches.
As I checked them out, most of them seem to make sense to me. :)
 
I have more queries. Would you please kindly answer to me?

1.
How can we send the touch pressure/area events via wayland protocol?
I know this question is something irrelative to libinput. I'd like to get your 
opinion. :)

Suppose now we have get touch pressure and area events as libinput events and 
in our wayland server is ready to dealing with them.
When it comes to sending those events (pressure, area) via wayland protocol, as 
we know, we can't send them because there are no arguments exist in the current 
latest version of wl_touch_interface.

There can be two or more ways to send the events to wayland client(s).
  - One is extending wayland protocol to have the more arguments.
  - The other is implementing our own wayland extension protocol for our 
wayland server and clients.
Can you tell me which one is more acceptable to you ? :)


2.
In Andreas Pokorny patch, only support part of standard linux MT protocols 
except ABS_MT_DISTANCE, ABS_MT_TOOL_TYPE, etc..
Do you have any plan to support whole MT protocol events? Or These events are 
meaningless to support via libinput?


3.
How can we deal with the additional MT protocol events in libinput, if our 
kernel support more MT protocol events than the events listed in input.h in 
libinput ?
Can they be supported ? Do you have any ideas?


Thank you in advance.
JengHyun Kang.

> -Original Message-
> From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> Sent: Tuesday, January 05, 2016 5:46 PM
> Cc: wayland-devel@lists.freedesktop.org; sj76.p...@samsung.com;
> duna...@samsung.com
> Subject: Re: [libinput] How I get extra touch events using libinput?
> 
> On Tue, Jan 05, 2016 at 05:01:33PM +0900,wrote:
> > Hello, guys.
> > I have a query regarding linux MT protocol event handling in libinput
> side.
> > I wanted to get the extra events such as ABS_MT_TOUCH_MAJOR,
> > ABS_MT_PRESSURE as an event of libinput, but I found that libinput
> > doesn't handle those events.
> >
> > Thus I'd like to know whether there is any plan regarding ABS_MT_XXX
> > event handling in libinput side.
> > If there are no plan to support those events, how can I handling those
> > events?
> 
> correct, there is currently no handling of these events, but Andreas
> Pokorny has a number of patches to add extra axes for touch events. I
> think this one was the last version:
> http://lists.freedesktop.org/archives/wayland-devel/2015-
> November/025415.html
> and the comments:
> http://lists.freedesktop.org/archives/wayland-devel/2015-
> November/025687.html
> 
> Cheers,
>Peter

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel