from:"박성진"

RE: Re: [PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

2018-11-27 Thread 박성진




> On Tue, 27 Nov 2018 17:59:16 +0900> 박성진  wrote:> > Hi Derek>> On 11/22/18 11:08 PM, Jeonghyun Kang wrote:> > > What if it's a frame event that gets dropped and not an input event?  Or> > > a resource destroy?> > Instead of destroying a connection, destroying a resource seems to be more> > reasonable.> No, you cannot do that either. It too will cause the client and the> server to get out of sync, which may eventually lead to a fatal> protocol error.> Really, the only thing you can do is either disconnect the client or> halt its connection until it drains. Halting would require explicit> support throughout the compositor to avoid sending any events, so> disconnecting is the only thing that libwayland-server can do by itself.
Oops ! Actually I had to say "removing/re-creating resources like wl_touch interfaceby updating capabilities via wl_seat capabilities event seems better than destroyingthe client." As we have an electronic whiteboard products that can be drawn with 4 penssimultaneouly in high resolution, killing an important app that draws trajectories ofeach pen may not be the best option.Anyway, There was a mis-understanding about dealing with EAGAIN inwl_display_flush_clients(). All the queued events in connection.out buffer in awayland compositor can be flushed to clients as there will be no protocol .By the way, trying to sending events when we meet EAGAIN error in wl_closure_send()/wl_close_queue() will cause dropping events. Thus, it's quite intentional not to deal withEAGAIN error in those functions.Now we're going to do the further analysis about how many events are coming fromkernel/compositor and how fast the client can process the events.
 
Thank you so much and we'll update if there are any valuable points.
Sung-Jin

No File Name 0
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Re: [PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

2018-11-27 Thread 박성진




Hi Derek>> On 11/22/18 11:08 PM, Jeonghyun Kang wrote:
>> When a wayland compositor gets an EAGAIN error whenever
>> sending or receiving event(s) to a client in the
>> wl_closure_send() or the wl_closure_queue(), the error
>> variable of the wl_client for the client will be set to
>> true and the client is going to be killed by the
>> compositor later soon. This patch fixes the problem by
>> updating the socket fd's event mask as we're doing
>> in wl_display_flush_clients() for having another chance
>> to do it again.
>> 
>> Actually, this kind of problem can be watched in an
>> environment in which massive input events are coming
>> from multi-touch screen or multi-pen devices. In this
>> kind of environment, a client receiving the massive
>> input events are trying to drawing something very hard
>> but it's being killed sooner or later. With the given
>> patch, the client receiving the input events is not being
>> destroyed and is working well even though it doesn't get
>> the whole input events from the compositor.

> This is actually intentional behavior to avoid infinitely growing send
> queues for clients that process events too slowly.I agree that we can easily find a client side problem that consumes eventstoo slowly. I wonder why we don't need to have EAGAIN handling logic inwl_closure_send(). As mentioned above, there is already an error handlinglogic of EAGAIN in wl_display_flush_clients(). Even if there is an error onflushing to a client in wl_display_flush_clients(), we'll have the nextchance to flush to the client. I think it is necessary to make it clear interms of consistency.
> I don't think dropping events randomly (or at all) because the client
> can't keep up is something we should do in libwayland. It'll just make
> for nearly impossible to reproduce and debug problems when client and
> compositor state fall out of sync.Agreed. Dropping events will cause many problems.By the way, when it failed to flush event(s) to a client, the event(s)will be dropped by default as wayland server library doesn't care about it.That's what I wanted to talk about.

> What if it's a frame event that gets dropped and not an input event?  Or
> a resource destroy?Instead of destroying a connection, destroying a resource seems to be morereasonable.

> The disconnect is a clear indication that there's a problem that needs
> to be fixed somewhere else. The client needs to process events in a
> timely fashion, or the compositor needs to send less events.Of course, in many case, optimization must be done in client side and we'realso doing many optimizations in client side and they're making the situationbetter. But I think it's not enough. IMO, we need to think aboutwhat's the proper value for the buffer size of wl_connection's in/out inwayland client and what's the effect of shrink/expand the size of the buffer.

ThanksSung-Jin

> Signed-off-by: jeon  >
> 
> ---
>  src/wayland-server.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index eae8d2e..5afaa28 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -222,8 +222,15 @@ handle_array(struct wl_resource *resource, uint32_t
> opcode,
>  
>     log_closure(resource, closure, true);
>  
> -   if (send_func(closure, resource->client->connection))
> -   resource->client->error = 1;
> +   if (send_func(closure, resource->client->connection)) {
> +   if (errno == EAGAIN) {
> +   wl_event_source_fd_update(resource->client->source,
> + WL_EVENT_WRITABLE |
> + WL_EVENT_READABLE);
> +   } else {
> +   resource->client->error = 1;
> +   }
> +   }
>  
>     wl_closure_destroy(closure);
>  }
> 
> -- 
> 2.7.4
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

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

RE: I've got a question to ask you

2018-08-27 Thread 박성진

Hi,
as weston creates libinput udev context by default, you'd better to prepare udev daemon for it.
Otherwise, you can create your own fbdev backend using libinput_path_create_context() / libinput_path_add_device().
Best regards,
Sung-Jin Park
- Original Message -
Sender : binnan hao
Date : 2018-08-28 12:35 (GMT+9)
Title : I've got a question to ask you

I've got a question to ask you. The Linux system I'm using is built on my own (Kernel+Busybox), and it does not contain other extra things. Now I want to use weston(fbdev-backend.so), but the keyboard and mouse do not work and log gives following message:

warning: no input devices on entering weston. possible causes:
- no permissions to read /dev/input/event*
- seats misconfigured (weston backend option 'seat', udev device property ID_SEAT)

I have root permission and device files can be found in path /dev/input/. I do not want to add anything else, as that may lead to a very large size system. Do you know any method to let weston use keyboard and mouse on my system?
--

Hao Binnan
Isoo (Qinhuangdao) software development Co., Ltd. (China)
http://www.eassos.com

PGP Public Key: 4096R/9EF21740 / 9678 1E8C B21E 1E60 3997 811D F83B B359 9EF2 1740
haobinnan ___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Re: Re: Questions about disabling key repeat for a keycode or a keysym

2016-04-26 Thread 박성진

Dear Ran,
thanks for your help. :)
As you commented, I put the repeat string and value into inet file.
It's succeed to control the repeat for each key. :)

I would consider proposing to add our custom keys to xproto, but I think there 
are also many product specific keys.
Thanks for your recommendation and I'll try to do it.

Regards,
Sung-Jin Park

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Ran Benita
Sent: Wednesday, April 20, 2016 10:16 PM
To: 박성진
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: Re: Re: Questions about disabling key repeat for a keycode or a 
keysym

On Wed, Apr 20, 2016 at 06:47:22AM +, 박성진 wrote:
> Dear Ran,
> what I did is following. :)
> 
> 1. define a custom keysym in libxkbcommon
>- add a custom keysym into xkbcommon/xkbcommon-keysyms.h file (e.g. 
> XF86VoiceWakeUp)
>- build ks_table.h again to reflect the custom keysym in 
> libxkbcommon 2. add a mapping between a keycode and a keysym in 
> xkeyboard-config
>- symbols/inet
>  key  { [XF86VoiceWakeUp ] }

I see there is already

key{  [ XF86Send  ]   };

in the "evdev" map; do you override it, or you're not using "evdev"?

Anyway, to make it not repeat, you can write this:

key  { [XF86VoiceWakeUp ], repeat=False }

> Is it enough information ? :)
> 
> And one more question is... what's the desirable way to define custom 
> keysyms and to do map between each keysym to each keycode ?

There is nothing stopping you from modifying xkbcommon-keysyms.h like you did, 
but note that xkbcommon-keysyms.h is generated from 
/usr/include/X11/keysymdef.h and other files, which are maintained in the 
"xproto" package[0]. So, if the keysyms you are adding make general sense, 
consider proposing to add them to xproto first. If they're accepted they will 
be added in a subsequent xkbcommon release.

[0] https://cgit.freedesktop.org/xorg/proto/xproto/

Alternatively, you can use an "anonymous" keysym, written like `0x123456`, with 
an appropriate value, then you can name it in your code instead of patching 
xkbcommon.

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

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

Re: Re: Re: Questions about disabling key repeat for a keycode or a keysym

2016-04-19 Thread 박성진

Dear Ran,
what I did is following. :)

1. define a custom keysym in libxkbcommon
   - add a custom keysym into xkbcommon/xkbcommon-keysyms.h file (e.g. 
XF86VoiceWakeUp)
   - build ks_table.h again to reflect the custom keysym in libxkbcommon
2. add a mapping between a keycode and a keysym in xkeyboard-config
   - symbols/inet
 key  { [XF86VoiceWakeUp ] }

Is it enough information ? :)

And one more question is... what's the desirable way to define custom keysyms 
and to do map between
each keysym to each keycode ?

Thanks and regards,
Sung-Jin Park


--- Original Message ---
Sender : Ran Benita 
Date   : 2016-04-19 19:51 (GMT+09:00)
Title  : Re: Re: Questions about disabling key repeat for a keycode or a keysym

On Tue, Apr 19, 2016 at 09:54:35AM +0000, 박성진 wrote:
> Dear Ran,
> thank you for your answer. :)
> 
> Plz kindly provide more details about it.
> We have defined some key symbols for built-in keys in mobile handset
> and would like to disable repeat for them.

Can you give an example of such a key symbol you do not want to repeat,
and how and where you defined it (xkb keymap file or elsewhere)?

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

Re: Re: Questions about disabling key repeat for a keycode or a keysym

2016-04-19 Thread 박성진

Dear Ran,
thank you for your answer. :)

Plz kindly provide more details about it.
We have defined some key symbols for built-in keys in mobile handset
and would like to disable repeat for them.

Thanks and regards,
Sung-Jin Park

--- Original Message ---
Sender : Ran Benita 
Date   : 2016-04-19 18:46 (GMT+09:00)
Title  : Re: Questions about disabling key repeat for a keycode or a keysym

The value returned by `xkb_keymap_key_repeats()` is determined by the
keymap. In xkeyboard-config, it is "calculated" automatically by a
mechanism called "interprets" in the "compat" section, but it can also
be set directly for a given key in the "symbols" section. I can provide
more details if you want.

So to change whether a key repeats at all or not, at least as far as
xkbcommon goes, you need to modify the keymap (i.e. xkeyboard-config).

Ran

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

Questions about disabling key repeat for a keycode or a keysym

2016-04-18 Thread 박성진

Title: Samsung Enterprise Portal mySingle


Dear all,
I wonder how I can disable key repeat for a specific keycode or a specific keysym.
We're using EFL (ecore wayland) to process key events and every keys are being repeated
based on the values like repeat delay, rate getting from wayland compositor.
I'd like to make some of keys not to be repeated.
As far as I know, there is not API for setting repeat flag for a keycode or a keysym.
Do I need to do something inside xkeyboard-config or to do with libxkbcommon API ?
Any suggestions ? :)
 
Thanks in advance,
Sung-Jin Park___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Re: Re: Question regarding joystick/gamepad support in wayland

2016-03-02 Thread 박성진

>I worry less about the joystick node here and more about the ability to open
>other event nodes that are keyboard, followed by sniffing every keyboard
>event that happens. If you have a process in place that checks which devices
>are joysticks and revokes them as needed, then this is mitigated somewhat.
Oh, I see. You meant an environment in which logind opens input device nodes
, allows a process to get the capability to access the nodes by requesting 
taking
device/control for the nodes.
In my environment, only js node can be read by non-root users.
Event nodes (of keyboard, mouse, ...) can only be read by root user.

Anyway, as logind provides an exclusive access for an input device with it's 
interface,
we can probably think about providing an exclusive access for the joystick 
device
with logind like approach.

--- Original Message ---
Sender : Peter Hutterer 
Date   : 2016-03-03 15:13 (GMT+09:00)
Title  : Re: Re: Question regarding joystick/gamepad support in wayland

On Thu, Mar 03, 2016 at 01:52:26AM +, 박성진 wrote:
>Dear Peter, thank you for your quick answer and I agree with you. :)
> 
>I have one more question below.
> 
> 
>>As for the most desirable way to support joysticks in Wayland - we
>don't
>>quite know, it'll depend on developers coming and saying "we need this
>and
>>that", then we can start a conversation on what to do. But right now
>it
>>seems a logind-like approach to allow an application to open js0 or
>the
>>event node is quite sufficient.
> 
>Do you imply that there will be security issues regarding the direct
>access
> 
>of the joystick node by an application ?
> 
>Did you mention logind-like approach for another reason ?
> 
>logind-like approach seems to be good for me, too, from the security
>point of view.
> 
>If the joystick node is able to be opened by any application directly
>and
> 
>(for instance) if a user starts a game application and tries to make
>any payment
> 
>in the game application with a joystick, i think it can make a security
>issue.
> 
>Of course, this is just an example and the payment for games needs
>to be made outside the game application. :)

I worry less about the joystick node here and more about the ability to open
other event nodes that are keyboard, followed by sniffing every keyboard
event that happens. If you have a process in place that checks which devices
are joysticks and revokes them as needed, then this is mitigated somewhat.

Cheers,
   Peter

> 
>--- Original Message ---
>Sender : Peter Hutterer
>Date   : 2016-03-03 08:42 (GMT+09:00)
>Title  : Re: Question regarding joystick/gamepad support in wayland
>On Wed, Mar 02, 2016 at 11:11:06PM +, wrote:
>> Dear all,
>> I would like to get your opinions regarding joystick/gamepad support
>in wayland.
>> What's the desirable way to support joystick/gamepad both in wayland
>and in linux ?
>> Plz kindly let me know if there is any previous discussion about
>this. :)
>>
>> Linux supports both joydev(e.g. /dev/input/js0) and evdev(e.g.
>/dev/input/event0) for joysticks/gamepads.
>> As far as I know, many games in linux open js node directly within
>the process itself and read/handle joystick events by itself.
>> Under Xorg window system, without having X events and X input
>extension events, why are the games opening joystick nodes directly ?
>> Are there any reason for doing that ? Are there any performance
>issues ? Otherwise, is it originated from the lack of X events for
>joystick?
>> Lastly, what the most desirable way to support joysticks/gamepads in
>wayland ?
>couple of things here:
>* joystick events require relatively little processing, they are mapped
>to a
>  function and that's about it. compare that with e.g. touchpads where
>a lot
>  of stuff is required before we know whether we should send a motion,
>  button or scroll event
>* joysticks do not have a standard set of functionality. they're all
>buttons
>  and axes but the layout changes, the functionality differs per
>device, etc.
>  this makes it really hard to come up with a generic library that
>handles
>  joysticks. and when you do, it'll likely look like evdev anyway
>* X hasn't really had joystick support, so now you have the inertia of
>  "everyone is doing it this way already". Couple this with the fact
>that
>  joysticks aren't used in the normal UI, they're dedicated devices
>

Re: Re: Question regarding joystick/gamepad support in wayland

2016-03-02 Thread 박성진

Title: Samsung Enterprise Portal mySingle


Dear Peter, thank you for your quick answer and I agree with you. :)
I have one more question below.
 
>As for the most desirable way to support joysticks in Wayland - we don't>quite know, it'll depend on developers coming and saying "we need this and>that", then we can start a conversation on what to do. But right now it>seems a logind-like approach to allow an application to open js0 or the>event node is quite sufficient.
Do you imply that there will be security issues regarding the direct access
of the joystick node by an application ?
Did you mention logind-like approach for another reason ?
logind-like approach seems to be good for me, too, from the security point of view.
If the joystick node is able to be opened by any application directly and
(for instance) if a user starts a game application and tries to make any payment
in the game application with a joystick, i think it can make a security issue.
Of course, this is just an example and the payment for games needs to be made outside the game application. :)
--- Original Message ---Sender : Peter Hutterer Date   : 2016-03-03 08:42 (GMT+09:00)Title  : Re: Question regarding joystick/gamepad support in waylandOn Wed, Mar 02, 2016 at 11:11:06PM +, 박성진 wrote:> Dear all,> I would like to get your opinions regarding joystick/gamepad support in wayland.> What's the desirable way to support joystick/gamepad both in wayland and in linux ?> Plz kindly let me know if there is any previous discussion about this. :)> > Linux supports both joydev(e.g. /dev/input/js0) and evdev(e.g. /dev/input/event0) for joysticks/gamepads.> As far as I know, many games in linux open js node directly within the process itself and read/handle joystick events by itself.> Under Xorg window system, without having X events and X input extension events, why are the games opening joystick nodes directly ?> Are there any reason for doing that ? Are there any performance issues ? Otherwise, is it originated from the lack of X events for joystick?> Lastly, what the most desirable way to support joysticks/gamepads in wayland ?couple of things here:* joystick events require relatively little processing, they are mapped to a  function and that's about it. compare that with e.g. touchpads where a lot  of stuff is required before we know whether we should send a motion,  button or scroll event* joysticks do not have a standard set of functionality. they're all buttons  and axes but the layout changes, the functionality differs per device, etc.  this makes it really hard to come up with a generic library that handles  joysticks. and when you do, it'll likely look like evdev anyway* X hasn't really had joystick support, so now you have the inertia of  "everyone is doing it this way already". Couple this with the fact that  joysticks aren't used in the normal UI, they're dedicated devices that  have a different functionality per application.As for the most desirable way to support joysticks in Wayland - we don'tquite know, it'll depend on developers coming and saying "we need this andthat", then we can start a conversation on what to do. But right now itseems a logind-like approach to allow an application to open js0 or theevent node is quite sufficient.Cheers,   Peter___wayland-devel mailing listwayland-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/wayland-devel  ___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Question regarding joystick/gamepad support in wayland

2016-03-02 Thread 박성진

Dear all,
I would like to get your opinions regarding joystick/gamepad support in wayland.
What's the desirable way to support joystick/gamepad both in wayland and in 
linux ?
Plz kindly let me know if there is any previous discussion about this. :)

Linux supports both joydev(e.g. /dev/input/js0) and evdev(e.g. 
/dev/input/event0) for joysticks/gamepads.
As far as I know, many games in linux open js node directly within the process 
itself and read/handle joystick events by itself.
Under Xorg window system, without having X events and X input extension events, 
why are the games opening joystick nodes directly ?
Are there any reason for doing that ? Are there any performance issues ? 
Otherwise, is it originated from the lack of X events for joystick?
Lastly, what the most desirable way to support joysticks/gamepads in wayland ?

Thank you for reading and for your response in advance.
Sung-Jin Park
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Re: Regarding user data for wl_client.

2016-01-27 Thread 박성진

Dear all and nicesj,
I push a patch to add get/set user data for wl_client.
If it does make sense, I think it'll be merged into the repository after 
getting reviewed.

Thanks and regards, 
Sung-Jin Park

--- Original Message ---
Sender : Giulio Camuffo 
Date   : 2016-01-27 19:14 (GMT+09:00)
Title  : Re: Regarding user data for wl_client.

2016-01-27 5:30 GMT+02:00  :
> Dear all,
>
> Currently, I'm writing a simple compositor for proving my thought.
>
> while implementing it, I found that the wl_client doesn't have the user data
> field.
>
> in the sever side, the wl_client is used in many callbacks for handling the
> request of clients.
>
> are there any functions like wl_client_set_user_data, get_user_data?

As Pekka said they are missing as of now, however there is a workaround: have a

struct my_client {
  wl_listener destroy_listener;
  ...
};

and set the listener on the wl_client with
wl_client_add_destroy_listener(wl_client,
&my_client.destroy_listener), you can then retrieve the my_client from
the wl_client by doing

struct wl_listener *l = wl_client_get_destroy_listener(wl_client, ...);
struct my_client *c = container_of(l, struct my_client, destroy_listener);


--
Giulio


>
> Best regards,
> Sungjae Park
>
>
> Sent from my android device.
> ___
> 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
  
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] server: Add an API to get the socket fd for a client

2016-01-13 Thread 박성진

>sorry, that sounds completely bogus and I never implied anything like that.
Oh, don't mention it. I misunderstood your comment. :)
I'm also sorry for I mentioned UID in my previous email.
I think that sounds stranges. I should have mentioned PID instead of UID.

>socketpair() is used for creating a connection before fork()'ing and
>exec()'ing a client process, so that the process starts with an already
>open connection. In that case, wl_client_get_credentials() provides
>wrong information. Particularly the returned PID will be the
>compositor's, not the client's. I do not know if the security context
>you are interested in suffers from the same problem.
Exactly. I understand what you mean and I won't suffer from the same problem.
After comparing pids from compositor's and the client's, I'll bypass to check 
of client's privilege
when the client equals to the compositor.

>Upstream Weston never sends requests to itself, FWIW. It does use
>socketpair() when launching special clients, though.

>Yes, this is clear, assuming the security context information you
>receive is actually always correct. I would assume it does not suffer
>from the same caveat as getsockopt(SO_PEERCRED), but I don't know that.
Yes, as I also think, the security context must always be correct when I pass 
the exact client's fd.
The library to get the security contexts from the file descriptor must 
guarantee that
the returned contexts are credible.

Thanks and regards,
Sung-Jin Park

--- Original Message ---
Sender : Pekka Paalanen 
Date   : 2016-01-13 19:35 (GMT+09:00)
Title  : Re: [PATCH] server: Add an API to get the socket fd for a client


 On Wed, 13 Jan 2016 10:02:18 + (GMT)
박성진  wrote:

> Samsung Enterprise Portal mySingle
> 
> Pekka Paalanen, thank you for your review on this. :)
> 
>  
> 
> >The fd may not always be from a socket file, it can also be from a call
> >to socketpair(2).
> 
> Yes, exactly.
> 
> >Please refer to wl_client_get_credentials() for the
> >caveat there, and evaluate whether it applies to your use case.
> >wl_client_get_fd() doc should probably have a "see also
> >wl_client_get_credentials()" so that someone reading the doc finds out
> >about socketpair().
> 
> I'll append "see also wl_client_get_credentials() to wl_client_get_fd() doc. 
> :)
> 
>  
> 
> Regarding your recommendation, as you meant, if I just need to distinguish 
> between
> the client's request and the request from compositor itself, it'll be better 
> to use
> wl_client_get_credentials() because comparing between the compositor's uid and
> the uid from the function will be enough to make a decision for sth.

Hi,

sorry, that sounds completely bogus and I never implied anything like
that.

socketpair() is used for creating a connection before fork()'ing and
exec()'ing a client process, so that the process starts with an already
open connection. In that case, wl_client_get_credentials() provides
wrong information. Particularly the returned PID will be the
compositor's, not the client's. I do not know if the security context
you are interested in suffers from the same problem.

Upstream Weston never sends requests to itself, FWIW. It does use
socketpair() when launching special clients, though.

> In my use case, I would like to get the client fd and check whether the client
> has the needed privilege for doing sth with a request. The security context 
> getting from
> the client fd will be used to check the client's privilege.

Yes, this is clear, assuming the security context information you
receive is actually always correct. I would assume it does not suffer
from the same caveat as getsockopt(SO_PEERCRED), but I don't know that.


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

Re: [PATCH] server: Add an API to get the socket fd for a client

2016-01-13 Thread 박성진

Title: Samsung Enterprise Portal mySingle






Pekka Paalanen, thank you for your review on this. :)
 
>The fd may not always be from a socket file, it can also be from a call>to socketpair(2).
Yes, exactly.
>Please refer to wl_client_get_credentials() for the>caveat there, and evaluate whether it applies to your use case.>wl_client_get_fd() doc should probably have a "see also>wl_client_get_credentials()" so that someone reading the doc finds out>about socketpair().
I'll append "see also wl_client_get_credentials() to wl_client_get_fd() doc. :)
 
Regarding your recommendation, as you meant, if I just need to distinguish between
the client's request and the request from compositor itself, it'll be better to use
wl_client_get_credentials() because comparing between the compositor's uid and
the uid from the function will be enough to make a decision for sth.
 
In my use case, I would like to get the client fd and check whether the client
has the needed privilege for doing sth with a request. The security context getting from
the client fd will be used to check the client's privilege.
>One should probably also document, that the fd you get from this>function is not duplicated, and it remains owned and used by>libwayland-server. Therefore if the caller does anything to the fd that>changes its state, it will likely cause problems. Getting the fd is for>inspection only, like the use case described in the commit message.>It might even make sense to add the example use case to the doc.Agree with you. I'll enhance the doc and update it soon.
 
Thanks and regards,
Sung-Jin Park--- Original Message ---Sender : Pekka Paalanen Date   : 2016-01-13 17:01 (GMT+09:00)Title  : Re: [PATCH] server: Add an API to get the socket fd for a client On Wed, 13 Jan 2016 10:31:58 +0800Jonas Adahl  wrote:> On Tue, Jan 12, 2016 at 10:58:16AM -0600, Derek Foreman wrote:> > On 11/01/16 04:30 PM, Sung-Jin Park wrote:  > > > This adds an API to get the socket fd for a client.> > > The client socket fd can be used for a wayland compositor to validate a request> > > from a client.> > > For instance, this will be helpful in some linux distributions, in which SELinux> > > or SMACK is enabled. In those environments, each file (including socket) will have> > > each security context in its inode as xattr member variable. A wayland compositor> > > can validate a client request by getting socket fd of the client and by checking> > > the security context associated with the socket fd.> > > > > > Signed-off-by: Sung-Jin Park > > > ---> > >  src/wayland-server-core.h |  3 +++> > >  src/wayland-server.c  | 15 +++> > >  2 files changed, 18 insertions(+)> > > > > > diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h> > > index 1700cd3..0d5fbc1 100644> > > --- a/src/wayland-server-core.h> > > +++ b/src/wayland-server-core.h> > > @@ -182,6 +182,9 @@ void> > >  wl_client_get_credentials(struct wl_client *client,> > >   pid_t *pid, uid_t *uid, gid_t *gid);> > >  > > > +int> > > +wl_client_get_socket_fd(struct wl_client *client);> > > +> > >  void> > >  wl_client_add_destroy_listener(struct wl_client *client,> > >    struct wl_listener *listener);> > > diff --git a/src/wayland-server.c b/src/wayland-server.c> > > index 55c0cf9..973a71c 100644> > > --- a/src/wayland-server.c> > > +++ b/src/wayland-server.c> > > @@ -491,6 +491,21 @@ wl_client_get_credentials(struct wl_client *client,> > >    *gid = client->ucred.gid;> > >  }> > >  > > > +/** Get the socket fd for the client  > > s/fd/file descriptor/> > > > + *> > > + * param client The display object> > > + * eturn fd The fd to use for the connection  > > > > Should probably just be> >  * eturn The fd to use for the connection  > > Maybe "file descriptor" here as well?> > > > > Otherwise this looks good to me,> > Reviewed-by: Derek Foreman   > > I would also prefer the API to be "wl_client_get_fd()" as that is that> is what all the other similar API looks like (be it a socket fd or a> non-socket fd).> > Other than those issues, this looks reasonable to me, so consider it> Reviewed-by: Jonas Adahl Hi,I agree with all of the above.The fd may not always be from a socket file, it can also be from a callto socketpair(2). Please refer to wl_client_get_credentials() for thecaveat there, and evaluate whether it applies to your use case.wl_client_get_fd() doc should probably have a "see alsowl_client_get_credentials()" so that someone reading the doc finds outabout socketpair().One should probably also document, that the fd you get from thisfunction is not duplicated, and it remains owned and used bylibwayland-server. Therefore if the caller does anything to the fd thatchanges its state, it will likely cause problems. Getting the fd is forinspection only, like the use case described in the commit message.It might even make sense to add the example use case to the doc.With these documentation additions, you getAcked-by: Pekka Paalanen Thanks,pq> >   > > > + *> > > + * T

[PATCH] server: Add an API to get the socket fd for a client

2016-01-11 Thread 박성진

>From 3bdb494aa2be26ed2b8ba9115994fd5f4939d5fa Mon Sep 17 00:00:00 2001

From: Sung-Jin Park 

Date: Mon, 11 Jan 2016 18:51:21 +0900

Subject: [PATCH] server: Add an API to get the socket fd for a client

 

This adds an API to get the socket fd for a client.

The client socket fd can be used for a wayland compositor to validate a
request

from a client.

For instance, this will be helpful in some linux distributions, in which
SELinux

or SMACK is enabled. In those environments, each file (including socket)
will have

each security context in its inode as xattr member variable. A wayland
compositor

can validate a client request by getting socket fd of the client and by
checking

the security context associated with the socket fd.

 

Signed-off-by: Sung-Jin Park 

---

src/wayland-server-core.h |  3 +++

src/wayland-server.c  | 15 +++

2 files changed, 18 insertions(+)

 

diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h

index 1700cd3..0d5fbc1 100644

--- a/src/wayland-server-core.h

+++ b/src/wayland-server-core.h

@@ -182,6 +182,9 @@ void

wl_client_get_credentials(struct wl_client *client,

 pid_t *pid, uid_t *uid, gid_t *gid);

+int

+wl_client_get_socket_fd(struct wl_client *client);

+

void

wl_client_add_destroy_listener(struct wl_client *client,

  struct wl_listener *listener);

diff --git a/src/wayland-server.c b/src/wayland-server.c

index 55c0cf9..973a71c 100644

--- a/src/wayland-server.c

+++ b/src/wayland-server.c

@@ -491,6 +491,21 @@ wl_client_get_credentials(struct wl_client *client,

*gid = client->ucred.gid;

}

+/** Get the socket fd for the client

+ *

+ * \param client The display object

+ * \return fd The fd to use for the connection

+ *

+ * This function returns the client socket fd for the given client.

+ *

+ * \memberof wl_client

+ */

+WL_EXPORT int

+wl_client_get_socket_fd(struct wl_client *client)

+{

+ return client->connection->fd;

+}

+

/** Look up an object in the client name space

  *

  * \param client The client object

-- 

1.9.1



0001-server-Add-an-API-to-get-the-socket-fd-for-a-client.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[libinput] A query regaring key remap functionality

2015-12-17 Thread 박성진

Dear all,

I have a query regarding key remap functionality.

As of now, there is no key remap functionality provided by libinput.

I’m thinking of having key remap functionality in libinput as one of the
existing device configuration features.

(Actually, I made a patch for libinput already and tested it.)

 

As we have a specific USB TV tuner remote controller named "au0828 IR
(Hauppauge HVR950Q)" and

when it's been plugged, a key was making a bad keycode(KEY_EXIT) different
from its original purpose of keycode (KEY_BACK).

 

I thought there will be more H/Ws in addition to "au0828 IR (Hauppauge
HVR950Q)" remote controller and

this is why I think the key remap feature can be a part of libinput device
configurations.

 

Plz kindly share you guys’ opinion. :D

 

Thanks,

Sung-Jin Park

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

RE: [PATCH wayland] add apis to enable/disable wayland debug at runtime

2015-11-13 Thread 박성진

Sorry, I attached the patch at the end of the following email. :)

Thanks,
Sung-Jin Park

-Original Message-
From: 박성진 [mailto:sj76.p...@samsung.com] 
Sent: Friday, November 13, 2015 7:33 PM
To: wayland-devel@lists.freedesktop.org
Cc: Sung-Jin Park/Common Platform Lab(S/W Center)/S5/Samsung Electronics
Subject: [PATCH wayland] add apis to enable/disable wayland debug at runtime

Hello,
I added two apis in wayland-util to enable/disable display of wayland debug
information at runtime.

I had a difficulty to see wayland debug information at runtime when I'd
like to debug both a compositor and client(s).
And I found that there is no proper apis yet to enable/disable wayland
debug information at runtime.

Actually, we already know that we can see wayland debug information by
setting WAYLAND_DEBUG environment to 1.
But the environment will merely check when a compositor creates a wayland
display or a client tries to connect to an wayland display.
IMO, it's better to have the additional apis to enable/disable wayland
debug information at runtime.
It would also help if we are to catch the problems associated with timing.

Plz kindly review this patch.

=

>From 018eec7b3a7a0667d25b116945a2c98dc914dc38 Mon Sep 17 00:00:00 2001
From: Sung-Jin Park 
Date: Fri, 13 Nov 2015 18:55:17 +0900
Subject: [PATCH] add apis to enable/disable wayland debug at runtime

---
 src/wayland-client.c  |  2 --
 src/wayland-private.h |  9 +
 src/wayland-server.c  |  2 --
 src/wayland-util.c| 15 +++
 4 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index b1c600f..151d18e 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -110,8 +110,6 @@ struct wl_display {

 /** \endcond */

-static int debug_client = 0;
-
 /**
  * This helper function wakes up all threads that are
  * waiting for display->reader_cond (i. e. when reading is done,
diff --git a/src/wayland-private.h b/src/wayland-private.h
index da9040a..3003417 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -206,6 +206,15 @@ wl_closure_print(struct wl_closure *closure,
 void
 wl_closure_destroy(struct wl_closure *closure);

+extern int debug_client;
+extern int debug_server;
+
+void
+wl_debug_client_enable(int enable);
+
+void
+wl_debug_server_enable(int enable);
+
 extern wl_log_func_t wl_log_handler;

 void wl_log(const char *fmt, ...);
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..c3c35ed 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -122,8 +122,6 @@ struct wl_resource {
wl_dispatcher_func_t dispatcher;
 };

-static int debug_server = 0;
-
 WL_EXPORT void
 wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
 union wl_argument *args)
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 00265e9..8f9f30b 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -33,6 +33,9 @@
 #include "wayland-util.h"
 #include "wayland-private.h"

+int debug_client = 0;
+int debug_server = 0;
+
 struct wl_object global_zombie_object;

 WL_EXPORT void
@@ -366,6 +369,18 @@ wl_map_for_each(struct wl_map *map, wl_iterator_func_t
func, void *data)
for_each_helper(&map->server_entries, func, data);
 }

+WL_EXPORT void
+wl_debug_client_enable(int enable)
+{
+   debug_client = !!enable;
+}
+
+WL_EXPORT void
+wl_debug_server_enable(int enable)
+{
+   debug_server = !!enable;
+}
+
 /** \endcond */

 static void
--
1.9.1

Thanks,
Sung-Jin Park


0001-add-apis-to-enable-disable-wayland-debug-at-runtime.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] add apis to enable/disable wayland debug at runtime

2015-11-13 Thread 박성진

Hello,
I added two apis in wayland-util to enable/disable display of wayland debug
information at runtime.

I had a difficulty to see wayland debug information at runtime when I'd
like to debug both a compositor and client(s).
And I found that there is no proper apis yet to enable/disable wayland
debug information at runtime.

Actually, we already know that we can see wayland debug information by
setting WAYLAND_DEBUG environment to 1.
But the environment will merely check when a compositor creates a wayland
display or a client tries to connect to an wayland display.
IMO, it's better to have the additional apis to enable/disable wayland
debug information at runtime.
It would also help if we are to catch the problems associated with timing.

Plz kindly review this patch.

Thanks,
Sung-Jin Park


0001-add-apis-to-enable-disable-wayland-debug-at-runtime.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

2015-10-18 Thread 박성진

>At least based on this example, I think this is fixing the wrong problem.
>knowing which device sends a key is fairly meaningless unless you have direct 
>access to the devices anyway (which you >probably don't, at least not in the 
>default setups). And there are plenty of devices that have meaningless names 
>made >from the pid/vid hex codes or even worse - "USB Keyboard".

Sorry for replying late. :)

Actually, as you mentioned, there are many keyboards which has {bus} Keyboard 
something like that.
I'm not telling that we need distinguish between a keyboard device (which 
doesn't have any unique name) and the others.

We need to distinguish between a specific key device and the others,
of course, the key device will have the its exact name which can be used as an 
identifier.
Then, there are some applications in which separate behavior needs to be done 
for each of key device.
Even though these kinds of requirements seem to be relatively rare, it'll be 
wonderful if it exists in protocol.
I'm mentioning from this point of view.

>the source of your problem is IMO that you're treating the remote control like 
>a keyboard when it isn't one. This is >what we've been trying to solve with 
>the buttonset interface in libinput (still WIP and needs a wayland protocol 
>>extension). Those devices are merely sets of buttons and require their own 
>focus control and behaviour, separate to >(and more domain-specific
>than) keyboards. But it moves the issue into its own separate corner where it 
>can be handled correctly, rather than >papering over the issues.

Right, by adding 'buttonset' into wayland protocol and by assigning a device as 
a buttonset device, we will be ready to have separate interface between 
keyboard and buttonset. Will there be any identifier in the buttonset interface?
When it comes to identification between buttonsets, it'll be also needed to 
identify each of them, if required.

Thanks and regards,
Sung-Jin park

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Peter Hutterer
Sent: Tuesday, October 13, 2015 2:01 PM
To: �ڼ���
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] Extending wayland protocol for helping a wayland client to 
identify the event source of device (pointer/keyboard)

On Fri, Sep 25, 2015 at 04:14:25PM +0900,  ڼwrote:
> Dear all,
> 
> Let me share a patch for extending wayland protocol for helping a 
> wayland client to identify which events are coming from which physical 
> keyboard/pointer device.
> 
> I  d like to discuss with you guys about this patch. : )
> 
> In this patch, I added   name   event both for wl_pointer and for 
> wl_keyboard.
> 
> Under wayland protocol applied this patch, a wayland compositor will 
> send the name event when a wayland client add a listener for 
> wl_pointer or wl_keyboard.
> 
> Then, the client can store the name of the keyboard or pointer and 
> will use it when it is required.
> 
>  
> 
> Usually in desktop environment, we don  t need to care the source 
> device name of events.
> 
> In vehicle, mobile and TV environment, there will be many input 
> devices and will be many special requirements for them.
> 
> For instance, in TV,   1   key in an usual keyboard will be used as a 
> character   1   and will be sent to the focus surface/window.
> 
> By the way   1   key in remote control for TV will be used as a action 
> key and will be sent to channel managing process which doesn  t have 
> any focus surface/window.
> 
> In addition to this example, there can be many examples.
> 
> Thus, I share this patch. Any ideas on this ? : )

At least based on this example, I think this is fixing the wrong problem.
knowing which device sends a key is fairly meaningless unless you have direct 
access to the devices anyway (which you probably don't, at least not in the 
default setups). And there are plenty of devices that have meaningless names 
made from the pid/vid hex codes or even worse - "USB Keyboard".

the source of your problem is IMO that you're treating the remote control like 
a keyboard when it isn't one. This is what we've been trying to solve with the 
buttonset interface in libinput (still WIP and needs a wayland protocol 
extension). Those devices are merely sets of buttons and require their own 
focus control and behaviour, separate to (and more domain-specific
than) keyboards. But it moves the issue into its own separate corner where it 
can be handled correctly, rather than papering over the issues.

Cheers,
   Peter

> 
> ==
> 
> From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001
> 
> From: Sung-Jin Park 
> 
> Date: Fri, 25 Sep 2015 14:01:57 +0900
> 
> Subject: [PATCH] Add name event for wl_pointer and wl_keyboard in 
> wayland
> 
> protocol
> 
>  
> 
> ---
> 
> protocol/wayland.xml | 38 --
> 
> 1 file changed, 36 insertions(+

RE: [Wayland1.5]CPU occupancy rate of Weston is 99%

2015-10-01 Thread 박성진

Dear Yang Andy,
You can trace the status of Weston with the following ways:

- Trace with WAYLAND_DEBUG environment variable
   export WAYLAND_DEBUG=1
   Run Weston
   Watch what's going on...

- Trace with wchan : you can see which system call is called by a process
   ps -aux | grep weston
   cat /proc/{pid of Weston}/wchan (with root privilege)
   The above command will display the system call called by Weston now.

- Trace with strace : you can see which system call is called by a process
continuously
   e.g. strace -p {pid of Weston} -f
   This will print a lot of system calls if it's not stuck in a specific
system call.
   If Weston is doing somethings in a loop, system calls for those things
will be displayed.

- Trace with ltrace : you can see which library call is called by a process
continuously

- Trace with gdb

I hope this will helpful to you.
Thank and regards,
Sung-Jin Park


-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
Behalf Of Pekka Paalanen
Sent: Thursday, October 01, 2015 7:31 PM
To: Yang Andy
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [Wayland1.5]CPU occupancy rate of Weston is 99%

On Thu, 1 Oct 2015 08:54:47 +
Yang Andy  wrote:

> Hi everyone
> When i run QT-Application on wayland/weston,sometimes there is NG 
> issue that CPU occupancy rate of Weston is 99%. The probability of 
> this NG issue is very low,but if the NG issue occur,CPU occupancy rate 
> of Weston retains 99%. Could anyone give me some advice on how to 
> track the NG issue of weston? And what factors could cause this issue? 
> Best regards. Andy

Hi,

you need to find out where Weston is spinning when it happens. Use gdb to
interrupt Weston several times and note the stack trace, or use a profiling
tool with stack traces.

List corruption often results in an endless loop in wl_list_for_each etc.


Thanks,
pq

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

Re: Re: [PATCH] libinput device capability modification regarding combo input devices

2015-09-29 Thread 박성진

Dear Peter,
from the techinical point of view, calling an API several times doesn't matter. 
I'm with you, 
as we call dequeue() for a queue to get the queued item in order.
Regarding a queue, we know that we're using a queue therefore we'll call 
dequeue in natural ways.
By the way, regarding a capability stuff, IMHO, by calling once we can get the 
whole capabilities of a device
and it's more intuitive way because the user of the API doesn't know that how 
many capabilities are in the device.
Actually, as of now, we need to make a loop to get whole capabilities properly.

Thanks and regards,
Sung-Jin Park

--- Original Message ---
Sender : Peter Hutterer 
Date   : 2015-09-26 13:09 (GMT+09:00)
Title  : Re: [PATCH] libinput device capability modification regarding combo
 input devices

On Fri, Sep 25, 2015 at 03:32:43PM +0900, 박성진 wrote:
> Dear Peter, thanks.
> That's right. If we modify the enum with the new one, ABI break will be made.
> Then how about add new capabilities ?
> IMO, it's better to get capabilities by calling once an API than calling 
> libinput_device_has_capability twice.

we can add new capabilities (we already have two scheduled for future
merging, tablet and buttonset) but I don't really see a technical reason why
calling the API twice is a problem. Can you expand on this?

Cheers,
   Peter

> Otherwise, we can enhance wayland protocol to get keyboard/pointer name from 
> the compositor by event(s).
> Please share your opinion.
> 
> Thanks and regards,
> Sung-Jin Park
> 
> -Original Message-
> From: Peter Hutterer [mailto:peter.hutte...@who-t.net] 
> Sent: Friday, September 25, 2015 3:13 PM
> To: ?
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH] libinput device capability modification regarding combo 
> input devices
> 
> On Wed, Sep 23, 2015 at 11:29:13AM +0900,  ?wrote:
> > Dear all,
> > 
> > as you guys know, there are some combo input devices which support 
> > both keyboard functionality and pointer functionality.
> > 
> > We can also see some of input devices supports both keyboard 
> > functionality and touch functionality.
> > 
> >  
> > 
> > In theory, each input device functionality needs to be provided 
> > through each kernel device node.
> > 
> > By the way, there are many combo input devices whose input events is 
> > coming from one device node.
> > 
> > Now and in near future, many vendors can make many combo input devices.
> > 
> >  
> > 
> > For these kinds of input devices, how about adding new enums for combo 
> > devices?
> > 
> > Otherewise, how about defining enums with masks ?
> > 
> >  
> > 
> > For example, we can modify the definition of 
> > libinput_device_capability enum like the following:
> > 
> >  
> > 
> > diff --git a/src/libinput.h b/src/libinput.h
> > 
> > index 9057446..458f256 100644
> > 
> > --- a/src/libinput.h
> > 
> > +++ b/src/libinput.h
> > 
> > @@ -51,14 +51,22 @@ enum libinput_log_priority {
> > 
> > /**
> > 
> >   * @ingroup device
> > 
> >   *
> > 
> > - * Capabilities on a device. A device may have one or more 
> > capabilities
> > 
> > + * Capability masks and capabilities on a device. A device may have 
> > + one or
> > more capabilities
> > 
> >   * at a time, capabilities remain static for the lifetime of the device.
> > 
> >   */
> > 
> > +#define LIBINPUT_DEVICE_CAP_KEYBOARD_MASK (1L<<0)
> > 
> > +#define LIBINPUT_DEVICE_CAP_POINTER_MASK (1L<<1)
> > 
> > +#define LIBINPUT_DEVICE_CAP_TOUCH_MASK (1L<<2)
> > 
> > +#define LIBINPUT_DEVICE_CAP_GESTURE_MASK (1L<<3)
> > 
> > +
> > 
> > enum libinput_device_capability {
> > 
> > -   LIBINPUT_DEVICE_CAP_KEYBOARD = 0,
> > 
> > -   LIBINPUT_DEVICE_CAP_POINTER = 1,
> > 
> > -   LIBINPUT_DEVICE_CAP_TOUCH = 2,
> > 
> > -   LIBINPUT_DEVICE_CAP_GESTURE = 5,
> > 
> > +   LIBINPUT_DEVICE_CAP_KEYBOARD = 
> > + LIBINPUT_DEVICE_CAP_KEYBOARD_MASK,
> > 
> > +   LIBINPUT_DEVICE_CAP_POINTER = 
> > + LIBINPUT_DEVICE_CAP_POINTER_MASK,
> > 
> > +   LIBINPUT_DEVICE_CAP_TOUCH = LIBINPUT_DEVICE_CAP_TOUCH_MASK,
> > 
> > +   LIBINPUT_DEVICE_CAP_GESTURE = 
> > + LIBINPUT_DEVICE_CAP_GESTURE_MASK,
> > 
> > +   LIBINPUT_DEVICE_CAP_KEYBOARD_POINTER =
> > LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_POINTER_MASK,
> > 
> > +   LIBINPUT_DEVI

[PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

2015-09-25 Thread 박성진

Dear all,

Let me share a patch for extending wayland protocol for helping a wayland
client to identify which events are coming from which physical
keyboard/pointer device.

I’d like to discuss with you guys about this patch. : )

In this patch, I added “name” event both for wl_pointer and for
wl_keyboard.

 

Under wayland protocol applied this patch, a wayland compositor will send
the name event when a wayland client add a listener for wl_pointer or
wl_keyboard.

Then, the client can store the name of the keyboard or pointer and will use
it when it is required.

 

Usually in desktop environment, we don’t need to care the source device
name of events.

In vehicle, mobile and TV environment, there will be many input devices and
will be many special requirements for them.

 

For instance, in TV, ‘1’ key in an usual keyboard will be used as a
character ‘1’ and will be sent to the focus surface/window.

By the way ‘1’ key in remote control for TV will be used as a action key
and will be sent to channel managing process which doesn’t have any focus
surface/window.

In addition to this example, there can be many examples.

Thus, I share this patch. Any ideas on this ? : )

 

Thanks and regards,

Sung-Jin Park

 

==

>From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001

From: Sung-Jin Park 

Date: Fri, 25 Sep 2015 14:01:57 +0900

Subject: [PATCH] Add name event for wl_pointer and wl_keyboard in wayland

protocol

 

---

protocol/wayland.xml | 38 --

1 file changed, 36 insertions(+), 2 deletions(-)

 

diff --git a/protocol/wayland.xml b/protocol/wayland.xml

index 42c9309..7e98720 100644

--- a/protocol/wayland.xml

+++ b/protocol/wayland.xml

@@ -1402,7 +1402,7 @@

 

   

 

-  

+  

 

   The wl_pointer interface represents one or more input devices,

   such as mice, which control the pointer location and pointer_focus

@@ -1569,9 +1569,26 @@

   

 

 

+

+

+

+  

+This can be used by the client to help identify which pointer
events

+come from which physical pointer device.

+

+In some cases, a specific client application can acts in different
ways

+when it gets pointer events from different pointer devices.

+For instance, a series of motion events coming from a mouse

+will be used as a cursor mover while the other series of motion
events coming

+from a pointer device which has a special wheel will be used as a
scroller

+of list of items.

+  

+  

+

+

   

 

-  

+  

 

   The wl_keyboard interface represents one or more keyboards

   associated with a seat.

@@ -1683,6 +1700,23 @@

   

 

+

+

+

+

+  

+This can be used by the client to help identify which key events

+come from which physical keyboard device.

+

+In some cases, a specific client application can acts in different
ways

+when it gets an identical key from different keyboard devices.

+For instance, in TV like environment, '1' key coming from a
keyboard

+will be used as a character. Meanwhile '1' key coming from a remote

+control key device will be used as a channel switching key.

+  

+  

+

+

   

 

   

--

1.9.1

 

 



0001-Add-name-event-for-wl_pointer-and-wl_keyboard-in-way.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: [PATCH] libinput device capability modification regarding combo input devices

2015-09-24 Thread 박성진

Dear Peter, thanks.
That's right. If we modify the enum with the new one, ABI break will be made.
Then how about add new capabilities ?
IMO, it's better to get capabilities by calling once an API than calling 
libinput_device_has_capability twice.

Otherwise, we can enhance wayland protocol to get keyboard/pointer name from 
the compositor by event(s).
Please share your opinion.

Thanks and regards,
Sung-Jin Park

-Original Message-
From: Peter Hutterer [mailto:peter.hutte...@who-t.net] 
Sent: Friday, September 25, 2015 3:13 PM
To: �ڼ���
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] libinput device capability modification regarding combo 
input devices

On Wed, Sep 23, 2015 at 11:29:13AM +0900,  ڼwrote:
> Dear all,
> 
> as you guys know, there are some combo input devices which support 
> both keyboard functionality and pointer functionality.
> 
> We can also see some of input devices supports both keyboard 
> functionality and touch functionality.
> 
>  
> 
> In theory, each input device functionality needs to be provided 
> through each kernel device node.
> 
> By the way, there are many combo input devices whose input events is 
> coming from one device node.
> 
> Now and in near future, many vendors can make many combo input devices.
> 
>  
> 
> For these kinds of input devices, how about adding new enums for combo 
> devices?
> 
> Otherewise, how about defining enums with masks ?
> 
>  
> 
> For example, we can modify the definition of 
> libinput_device_capability enum like the following:
> 
>  
> 
> diff --git a/src/libinput.h b/src/libinput.h
> 
> index 9057446..458f256 100644
> 
> --- a/src/libinput.h
> 
> +++ b/src/libinput.h
> 
> @@ -51,14 +51,22 @@ enum libinput_log_priority {
> 
> /**
> 
>   * @ingroup device
> 
>   *
> 
> - * Capabilities on a device. A device may have one or more 
> capabilities
> 
> + * Capability masks and capabilities on a device. A device may have 
> + one or
> more capabilities
> 
>   * at a time, capabilities remain static for the lifetime of the device.
> 
>   */
> 
> +#define LIBINPUT_DEVICE_CAP_KEYBOARD_MASK (1L<<0)
> 
> +#define LIBINPUT_DEVICE_CAP_POINTER_MASK (1L<<1)
> 
> +#define LIBINPUT_DEVICE_CAP_TOUCH_MASK (1L<<2)
> 
> +#define LIBINPUT_DEVICE_CAP_GESTURE_MASK (1L<<3)
> 
> +
> 
> enum libinput_device_capability {
> 
> -   LIBINPUT_DEVICE_CAP_KEYBOARD = 0,
> 
> -   LIBINPUT_DEVICE_CAP_POINTER = 1,
> 
> -   LIBINPUT_DEVICE_CAP_TOUCH = 2,
> 
> -   LIBINPUT_DEVICE_CAP_GESTURE = 5,
> 
> +   LIBINPUT_DEVICE_CAP_KEYBOARD = 
> + LIBINPUT_DEVICE_CAP_KEYBOARD_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_POINTER = 
> + LIBINPUT_DEVICE_CAP_POINTER_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_TOUCH = LIBINPUT_DEVICE_CAP_TOUCH_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_GESTURE = 
> + LIBINPUT_DEVICE_CAP_GESTURE_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_KEYBOARD_POINTER =
> LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_POINTER_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_KEYBOARD_TOUCH =
> LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_TOUCH_MASK,
> 
> +   LIBINPUT_DEVICE_CAP_TOUCH_GESTURE = 
> + LIBINPUT_DEVICE_CAP_TOUCH_MASK
> | LIBINPUT_DEVICE_CAP_GESTURE_MASK,
> 
> };
> 
>  
> 
> /**
> 
> With this kinds of modification,
> 
> A wayland compositor is able to recognize the actual input device 
> capabilities and able to interpret events properly.
> 
>  
> 
> Any ideas ?

Two things: libinput's API has been stable for a while now and cannot be 
changed, you can only add to it in backwards-compatible manner. The above isn't 
backwards-compatible, so it's a non-starter.

The mask-like behaviour you ask for is provided by these enums. if you want to 
check if a device is both pointer and keyboard, you call 
libinput_device_has_capability twice, once with CAP_POINTER, once with 
CAP_KEYBOARD. There's no need for specific combination defines or masks.

Cheers,
   Peter

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

RE: [PATCH] libinput device capability modification regarding combo input devices

2015-09-24 Thread 박성진

Dear Bill Spitzak, thanks for your opinion. : )

 

As we know, there are a lot of keyboards or keyboard-like devices.

Some of them will be keypads or special keyboards for game or other purposes.

For those kinds of keyboards, we don’t need to care and we can deal with the 
events in the usual manner (e.g. send them to focus surface/window).

 

When it comes to mobile or TV, we can have another stories.

In mobile/TV, in some cases, we need to deal with a set of keys attached in the 
device in a special manner, therefore we need to distinguish the keys in the 
set from the normal keyboard keys.

 

For instance, in mobile, we can see some keys attached in our mobile devices.

Those kinds of keys are usually not for input texts but for triggering some 
actions.

In a usual application, volume up/down keys will be the keys for 
raising/lowering the volume.

By the way, in an application like a message application, volume up/down keys 
can be used to adjust the font size.

Therefore each key attached in mobile device needs to be sent to each needed 
surface/window in a dynamically changeable delivery policy for each key because 
there are many applications which want to get a key even they don’t have the 
input focus.

Actually in many requirements in mobile devices, distinguishing between the 
normal(?) keyboards and the special set of key/buttons are needed and we need 
to have a key delivery manager which resides in a window manager for sending 
the special set of keys to the proper application(s).

 

Thanks and regards,

Sung-Jin Park

 

From: Bill Spitzak [mailto:spit...@gmail.com] 
Sent: Friday, September 25, 2015 4:37 AM
To: 박성진
Cc: Andreas Pokorny; Peter Hutterer; wayland
Subject: Re: [PATCH] libinput device capability modification regarding combo 
input devices

 

 

 

On Wed, Sep 23, 2015 at 6:52 PM, 박성진  wrote:

Dear Andreas Pokorny, thanks for your reply. J

 

As you mentioned, we also need to distinguish between a full keyboard and a 
device which has a set of few keys.

Each key coming from the full keyboard will be sent to the focus 
surface(window).

However, a key coming from the device which has a few keys sometimes needs to 
be sent to the other surface(window) other than the focused surface(window).

 

Seems like the keyboard flag can just indicate a "full keyboard". It is hard to 
imagine an input device that does not have a few buttons so this can be assumed.

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

RE: [PATCH] libinput device capability modification regarding combo input devices

2015-09-23 Thread 박성진

Dear Andreas Pokorny, thanks for your reply. J

 

As you mentioned, we also need to distinguish between a full keyboard and a 
device which has a set of few keys.

Each key coming from the full keyboard will be sent to the focus 
surface(window).

However, a key coming from the device which has a few keys sometimes needs to 
be sent to the other surface(window) other than the focused surface(window).

 

Dear Peter Hutterer, any ideas on this patch ? J

 

Thanks and regards,

Sung-Jin Park

 

From: Andreas Pokorny [mailto:andreas.poko...@gmail.com] 
Sent: Wednesday, September 23, 2015 3:48 PM
To: 박성진
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] libinput device capability modification regarding combo 
input devices

 

Hi,

2015-09-23 4:29 GMT+02:00 박성진 :

Dear all,

as you guys know, there are some combo input devices which support both 
keyboard functionality and pointer functionality.

We can also see some of input devices supports both keyboard functionality and 
touch functionality.

 

In theory, each input device functionality needs to be provided through each 
kernel device node.

By the way, there are many combo input devices whose input events is coming 
from one device node.

Now and in near future, many vendors can make many combo input devices.

 

For these kinds of input devices, how about adding new enums for combo devices?

Otherewise, how about defining enums with masks ?



For that reason we do use masks inside mir to describe input devices. We do use 
a few additional masks to also indicate whether the device, i.e. it might be 
interesting to know whether the device is a full keyboard or just offers a few 
buttons.. So yes I aggree with that. Right now we do the evdev based device 
detection in parallel to what udevd and libinput do.. 

regards

Andreas Pokorny

 

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

[PATCH] libinput device capability modification regarding combo input devices

2015-09-22 Thread 박성진

Dear all,

as you guys know, there are some combo input devices which support both
keyboard functionality and pointer functionality.

We can also see some of input devices supports both keyboard functionality
and touch functionality.

 

In theory, each input device functionality needs to be provided through
each kernel device node.

By the way, there are many combo input devices whose input events is coming
from one device node.

Now and in near future, many vendors can make many combo input devices.

 

For these kinds of input devices, how about adding new enums for combo
devices?

Otherewise, how about defining enums with masks ?

 

For example, we can modify the definition of libinput_device_capability
enum like the following:

 

diff --git a/src/libinput.h b/src/libinput.h

index 9057446..458f256 100644

--- a/src/libinput.h

+++ b/src/libinput.h

@@ -51,14 +51,22 @@ enum libinput_log_priority {

/**

  * @ingroup device

  *

- * Capabilities on a device. A device may have one or more capabilities

+ * Capability masks and capabilities on a device. A device may have one or
more capabilities

  * at a time, capabilities remain static for the lifetime of the device.

  */

+#define LIBINPUT_DEVICE_CAP_KEYBOARD_MASK (1L<<0)

+#define LIBINPUT_DEVICE_CAP_POINTER_MASK (1L<<1)

+#define LIBINPUT_DEVICE_CAP_TOUCH_MASK (1L<<2)

+#define LIBINPUT_DEVICE_CAP_GESTURE_MASK (1L<<3)

+

enum libinput_device_capability {

-   LIBINPUT_DEVICE_CAP_KEYBOARD = 0,

-   LIBINPUT_DEVICE_CAP_POINTER = 1,

-   LIBINPUT_DEVICE_CAP_TOUCH = 2,

-   LIBINPUT_DEVICE_CAP_GESTURE = 5,

+   LIBINPUT_DEVICE_CAP_KEYBOARD = LIBINPUT_DEVICE_CAP_KEYBOARD_MASK,

+   LIBINPUT_DEVICE_CAP_POINTER = LIBINPUT_DEVICE_CAP_POINTER_MASK,

+   LIBINPUT_DEVICE_CAP_TOUCH = LIBINPUT_DEVICE_CAP_TOUCH_MASK,

+   LIBINPUT_DEVICE_CAP_GESTURE = LIBINPUT_DEVICE_CAP_GESTURE_MASK,

+   LIBINPUT_DEVICE_CAP_KEYBOARD_POINTER =
LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_POINTER_MASK,

+   LIBINPUT_DEVICE_CAP_KEYBOARD_TOUCH =
LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_TOUCH_MASK,

+   LIBINPUT_DEVICE_CAP_TOUCH_GESTURE = LIBINPUT_DEVICE_CAP_TOUCH_MASK
| LIBINPUT_DEVICE_CAP_GESTURE_MASK,

};

 

/**

With this kinds of modification,

A wayland compositor is able to recognize the actual input device
capabilities and able to interpret events properly.

 

Any ideas ?

 

Thanks and regards,

Sung-Jin Park

 

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

RE: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

2015-06-02 Thread 박성진

Dear Daniel and Jasper St.Pierre,

thank you for your opinion !

 

There is a key processing module as a plugin module of a wayland compositor and 
it has data structures tightly coupled with a keycode.

I’m considering to re-write the data structures which contain keysym type 
variable instead of keycode variable.

 

Thanks and regards,

Sung-Jin Park

 

From: magc...@gmail.com [mailto:magc...@gmail.com] On Behalf Of Jasper St. 
Pierre
Sent: Tuesday, June 02, 2015 12:41 AM
To: Daniel Stone
Cc: sj76.p...@samsung.com; Ran Benita; wayland-devel@lists.freedesktop.org
Subject: Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from 
xkb_keysym_t.

 

Note that there are non-obvious consequences to this. The keymap is 
hierarchical upon layouts and levels. You can either do a depth-first search, 
or a breadth-first search. This can change behavior. XKeysymToKeycode is 
documented as doing a breadth-first search. This can have consequences in 
behavior. See:

https://git.gnome.org/browse/mutter/commit/src/core/keybindings.c?id=60c22b62366d737f7f6eabe7d46fa682c6f400d7

I'd highly recommend doing keygrabs on keysyms if you do want to let your 
clients do key grabs at all.

 

On Mon, Jun 1, 2015 at 6:02 AM, Daniel Stone  wrote:

Hi,

 

On 1 June 2015 at 12:22, 박성진  wrote:

Actually, we'd like to provide a key grab protocol to wayland client(s)

with which each client can make request to grab a key to wayland compositor.

To use the protocol, we need to provide one or more keycodes associated with a 
given keysym to the compositor as an argument.

At this moment we would like to call the following API to get keycode(s) from a 
keysym if exist.

Could you share your opinion ?

 

You might be better off asking to grab on a particular keysym instead, since 
the compositor always needs to track the current state so can trivially extract 
the keysym.

  

/**

 @param[in] keymap : xkb_keymap pointer

 @param[in] keysym : xkb_keysym_t keysym

 @param[out] keycodes array : xkb_keycode_t pointer

 @return number of keycodes found on success, otherwise -1

*/

XKB_EXPORT int xkb_keycodes_from_keysym(struct xkb_keymap *keymap, xkb_keysym_t 
keysym, xkb_keycode_t *keycodes);

or XKB_EXPORT int xkb_keymap_keycodes_from_keysym(struct xkb_keymap *keymap, 
xkb_keysym_t keysym, xkb_keycode_t *keycodes);

On the face of it, this seems okay, except you might want to document that 0 is 
a valid, non-error, return code; presumably in order to deal with keycode 
allocation, you would have to do something like:

xkb_keycode_t *keycodes;

int num_keycodes;

 

num_keycodes = xkb_keymap_keycodes_from_keysym(keymap, keysym, NULL);

if (num_keycodes == -1)

return -1;

else if (num_keycodes == 0)

return 1; /* still succeeded, just don't have any keycodes */

 

keycodes = malloc(num_keycodes * sizeof(*keycodes));

num_keycodes = xkb_keymap_keycodes_from_keysym(keymap, keysym, keycodes);

 

Cheers,

Daniel

 

Thanks and regards,

Sung-Jin Park

 

--- Original Message ---

Sender : Daniel Stone

Date : 2015-06-01 18:57 (GMT+09:00)

Title : Re: [libxkbcommon] Question about how to get xkb_keycode_t from 
xkb_keysym_t.

 

Hi Sung-Jin, 

 

On 1 June 2015 at 07:16, Sung-Jin Park  wrote:

I'd like to ask how to get keycode(s) from keysym using libxkbcommon API.

Is there any API in libxkbcommon ?

 

The short answer is, no.

 

The long answer is, look through the keymap and find every keycode which 
produces that keysym, which may be on various layouts (groups) or shift levels.

 

If you can share more details of what you actually want to achieve, that might 
be helpful.

 

Cheers,

Daniel 

 

 




  
<http://ext.samsung.net/mailcheck/SeenTimeChecker?do=2ca45776e672e14d572869ec7757a5c52acea990db9004c361cedcb6724b56210beae83852bfee8031ac65c790352a7bd5d78d49b87aef04f866eba98cb7300acf878f9a26ce15a0>
 

 


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




-- 

  Jasper

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

Fwd: Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

2015-06-01 Thread 박성진

Resend not to make this mail scrubbed. Sorry. :)

--- Original Message ---
Sender : 박성진 S5(책임)/책임/Common Platform Lab(S/W센터)/삼성전자
Date : 2015-06-01 20:22 (GMT+09:00)
Title : Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from 
xkb_keysym_t.

Dear Daniel, thanks for your quick answer. :)
In theory, one or more keysym can be mapped to each corresponding keycode
therefore we need to look through the keymap to find them out. I agree with you 
on that. :)

Actually, we'd like to provide a key grab protocol to wayland client(s)
with which each client can make request to grab a key to wayland compositor.
To use the protocol, we need to provide one or more keycodes associated with a 
given keysym to the compositor as an argument.
At this moment we would like to call the following API to get keycode(s) from a 
keysym if exist.
Could you share your opinion ?

/**
 @param[in] keymap : xkb_keymap pointer
 @param[in] keysym : xkb_keysym_t keysym
 @param[out] keycodes array : xkb_keycode_t pointer
 @return number of keycodes found on success, otherwise -1
*/
XKB_EXPORT int xkb_keycodes_from_keysym(struct xkb_keymap *keymap, xkb_keysym_t 
keysym, xkb_keycode_t *keycodes);
or XKB_EXPORT int xkb_keymap_keycodes_from_keysym(struct xkb_keymap *keymap, 
xkb_keysym_t keysym, xkb_keycode_t *keycodes);

Thanks and regards,
Sung-Jin Park

--- Original Message ---
Sender : Daniel Stone
Date : 2015-06-01 18:57 (GMT+09:00)
Title : Re: [libxkbcommon] Question about how to get xkb_keycode_t from 
xkb_keysym_t.

Hi Sung-Jin, 


On 1 June 2015 at 07:16, Sung-Jin Park  wrote:

I'd like to ask how to get keycode(s) from keysym using libxkbcommon API.

Is there any API in libxkbcommon ?


The short answer is, no.


The long answer is, look through the keymap and find every keycode which 
produces that keysym, which may be on various layouts (groups) or shift levels.


If you can share more details of what you actually want to achieve, that might 
be helpful.


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

Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

2015-06-01 Thread 박성진

Title: Samsung Enterprise Portal mySingle


Dear Daniel, thanks for your quick answer. :)
In theory, one or more keysym can be mapped to each corresponding keycode
therefore we need to look through the keymap to find them out. I agree with you on that. :)
 
Actually, we'd like to provide a key grab protocol to wayland client(s)
with which each client can make request to grab a key to wayland compositor.
To use the protocol, we need to provide one or more keycodes associated with a given keysym to the compositor as an argument.
At this moment we would like to call the following API to get keycode(s) from a keysym if exist.
Could you share your opinion ?
 
/**
 @param[in] keymap : xkb_keymap pointer
 @param[in] keysym : xkb_keysym_t keysym
 @param[out] keycodes array : xkb_keycode_t pointer
 @return number of keycodes found on success, otherwise -1
*/
XKB_EXPORT int xkb_keycodes_from_keysym(struct xkb_keymap *keymap, xkb_keysym_t keysym, xkb_keycode_t *keycodes);
or XKB_EXPORT int xkb_keymap_keycodes_from_keysym(struct xkb_keymap *keymap, xkb_keysym_t keysym, xkb_keycode_t *keycodes);
 
Thanks and regards,
Sung-Jin Park
 
--- Original Message ---
Sender : Daniel Stone
Date : 2015-06-01 18:57 (GMT+09:00)
Title : Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.
 
Hi Sung-Jin, 

On 1 June 2015 at 07:16, Sung-Jin Park  wrote:


I'd like to ask how to get keycode(s) from keysym using libxkbcommon API.
Is there any API in libxkbcommon ?

The short answer is, no.

The long answer is, look through the keymap and find every keycode which produces that keysym, which may be on various layouts (groups) or shift levels.

If you can share more details of what you actually want to achieve, that might be helpful.

Cheers,
Daniel 
 
 




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

Re: [Dev] HW key event grabbing on Tizen Wayland

2014-08-12 Thread 박성진

Title: Samsung Enterprise Portal mySingle

Hi, Wang, Yan,
libinput is a library to handle input devices and it'll be used for a display server like Xserver and wayland compositors.
Wayland clients will get input events through GUI toolkits from wayland compositors.
Regarding utilx library, the key definitions in it had been made for mobile profile on X based window system.
This kind of key definitions won't be made in wayland because the key list will be different from H/Ws and
the list of keys must not be hard-coded. :)
We're going to propose a new protocol for wayland clients
to make a request for H/W key event and to get the key event from wayland compositor.
Thanks and regards,Sung-Jin Park--- Original Message ---Sender : Wang, Yan Date : 2014-08-12 17:08 (GMT+09:00)Title : [Dev] HW key event grabbing on Tizen WaylandHi, All, Today I checked HW key event grabbing on Tizen. In Tizen X (mobile), libslp-utilx package could do this. (E.g. KEY_MENU/POWER/VOLUME_UP/VOLLUME_DOWN/CAMERA...) But how about in Wayland? In Wayland/Weston upstream, I think libinput could do it because I could see KEY_VOLUME_UP/DOWN, KEY_POWER, KEY_BACK, KEY_MENU, ... in it. Is it right? http://cgit.freedesktop.org/wayland/libinput. libinput hasn't been migrated to Tizen Wayland Common/IVI repos so far. Will it be available on Tizen in the future? Thanks.Yan Wang___Dev mailing listd...@lists.tizen.orghttps://lists.tizen.org/listinfo/dev ___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Re: [PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

RE: Re: [PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

RE: I've got a question to ask you

RE: Re: Re: Questions about disabling key repeat for a keycode or a keysym

Re: Re: Re: Questions about disabling key repeat for a keycode or a keysym

Re: Re: Questions about disabling key repeat for a keycode or a keysym

Questions about disabling key repeat for a keycode or a keysym

Re: Re: Re: Question regarding joystick/gamepad support in wayland

Re: Re: Question regarding joystick/gamepad support in wayland

Question regarding joystick/gamepad support in wayland

Re: Re: Regarding user data for wl_client.

Re: [PATCH] server: Add an API to get the socket fd for a client

Re: [PATCH] server: Add an API to get the socket fd for a client

[PATCH] server: Add an API to get the socket fd for a client

[libinput] A query regaring key remap functionality

RE: [PATCH wayland] add apis to enable/disable wayland debug at runtime

[PATCH wayland] add apis to enable/disable wayland debug at runtime

RE: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

RE: [Wayland1.5]CPU occupancy rate of Weston is 99%

Re: Re: [PATCH] libinput device capability modification regarding combo input devices

[PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

RE: [PATCH] libinput device capability modification regarding combo input devices

RE: [PATCH] libinput device capability modification regarding combo input devices

RE: [PATCH] libinput device capability modification regarding combo input devices

[PATCH] libinput device capability modification regarding combo input devices

RE: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

Fwd: Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

Re: Re: [libxkbcommon] Question about how to get xkb_keycode_t from xkb_keysym_t.

Re: [Dev] HW key event grabbing on Tizen Wayland

29 matches

Site Navigation

Mail list logo

Footer information