Re: [PATCH] XF86keysym: Add XF86XK_RotationLockToggle
Hi, On 22-01-19 03:47, Jian-Hong Pan wrote: Peter Hutterer 於 2019年1月22日 週二 上午9:03寫道： On Mon, Jan 21, 2019 at 08:23:08PM +0100, Hans de Goede wrote: Add XF86XK_RotationLockToggle keysym, to be used as mapping for evdev's KEY_ROTATE_LOCK_TOGGLE. I've a Point of View P1006W-232 Windows tablet which actually has a rotate-lock toggle-button. The latest kernel correctly generates KEY_ROTATE_LOCK_TOGGLE events for this. So now I'm hooking up support for it through all the higher layers. Signed-off-by: Hans de Goede Reviewed-by: Peter Hutterer Reviewed-by: Jian-Hong Pan Peter, Jian-Hong, Thank you for the reviews. I've pushed this patch now. Regards, Hans --- include/X11/XF86keysym.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/X11/XF86keysym.h b/include/X11/XF86keysym.h index 9ad8948..dd287e2 100644 --- a/include/X11/XF86keysym.h +++ b/include/X11/XF86keysym.h @@ -205,6 +205,8 @@ #define XF86XK_AudioPreset 0x1008FFB6 /* Select equalizer preset, e.g. theatre-mode */ +#define XF86XK_RotationLockToggle 0x1008FFB7 /* Toggle screen rotation lock on/off */ + /* Keys for special action keys (hot keys) */ /* Virtual terminals on some operating systems */ #define XF86XK_Switch_VT_1 0x1008FE01 -- 2.20.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] XF86keysym: Add XF86XK_RotationLockToggle
On Mon, Jan 21, 2019 at 08:23:08PM +0100, Hans de Goede wrote: > Add XF86XK_RotationLockToggle keysym, to be used as mapping for evdev's > KEY_ROTATE_LOCK_TOGGLE. > > I've a Point of View P1006W-232 Windows tablet which actually has a > rotate-lock toggle-button. The latest kernel correctly generates > KEY_ROTATE_LOCK_TOGGLE events for this. So now I'm hooking up support for > it through all the higher layers. > > Signed-off-by: Hans de Goede Reviewed-by: Peter Hutterer Cheers, Peter > --- > include/X11/XF86keysym.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/X11/XF86keysym.h b/include/X11/XF86keysym.h > index 9ad8948..dd287e2 100644 > --- a/include/X11/XF86keysym.h > +++ b/include/X11/XF86keysym.h > @@ -205,6 +205,8 @@ > > #define XF86XK_AudioPreset 0x1008FFB6 /* Select equalizer preset, e.g. > theatre-mode */ > > +#define XF86XK_RotationLockToggle 0x1008FFB7 /* Toggle screen rotation lock > on/off */ > + > /* Keys for special action keys (hot keys) */ > /* Virtual terminals on some operating systems */ > #define XF86XK_Switch_VT_1 0x1008FE01 > -- > 2.20.1 > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] XF86keysym: Add XF86XK_RotationLockToggle
Add XF86XK_RotationLockToggle keysym, to be used as mapping for evdev's KEY_ROTATE_LOCK_TOGGLE. I've a Point of View P1006W-232 Windows tablet which actually has a rotate-lock toggle-button. The latest kernel correctly generates KEY_ROTATE_LOCK_TOGGLE events for this. So now I'm hooking up support for it through all the higher layers. Signed-off-by: Hans de Goede --- include/X11/XF86keysym.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/X11/XF86keysym.h b/include/X11/XF86keysym.h index 9ad8948..dd287e2 100644 --- a/include/X11/XF86keysym.h +++ b/include/X11/XF86keysym.h @@ -205,6 +205,8 @@ #define XF86XK_AudioPreset 0x1008FFB6 /* Select equalizer preset, e.g. theatre-mode */ +#define XF86XK_RotationLockToggle 0x1008FFB7 /* Toggle screen rotation lock on/off */ + /* Keys for special action keys (hot keys) */ /* Virtual terminals on some operating systems */ #define XF86XK_Switch_VT_1 0x1008FE01 -- 2.20.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorgproto] XF86keysym: Add XF86XK_MonBrightnessCycle
Hi, Thank you for your patch. On 04-01-19 04:36, Jian-Hong Pan wrote: Jian-Hong Pan 於 2018年11月28日 週三 下午5:07寫道： Add XF86XK_MonBrightnessCycle keysym, to be used as mapping for evdev's KEY_BRIGHTNESS_CYCLE keycode which is generated from ACPI video module's ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS on some Acer AIO desktop buttons. The button changes the screen's brightness on Windows. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=108861 Signed-off-by: Jian-Hong Pan --- include/X11/XF86keysym.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/include/X11/XF86keysym.h b/include/X11/XF86keysym.h index 771fbb0..9ad8948 100644 --- a/include/X11/XF86keysym.h +++ b/include/X11/XF86keysym.h @@ -23,11 +23,12 @@ #define XF86XK_ModeLock0x1008FF01 /* Mode Switch Lock */ /* Backlight controls. */ -#define XF86XK_MonBrightnessUp 0x1008FF02 /* Monitor/panel brightness */ -#define XF86XK_MonBrightnessDown 0x1008FF03 /* Monitor/panel brightness */ -#define XF86XK_KbdLightOnOff 0x1008FF04 /* Keyboards may be lit */ -#define XF86XK_KbdBrightnessUp 0x1008FF05 /* Keyboards may be lit */ -#define XF86XK_KbdBrightnessDown 0x1008FF06 /* Keyboards may be lit */ +#define XF86XK_MonBrightnessUp0x1008FF02 /* Monitor/panel brightness */ +#define XF86XK_MonBrightnessDown 0x1008FF03 /* Monitor/panel brightness */ +#define XF86XK_KbdLightOnOff 0x1008FF04 /* Keyboards may be lit */ +#define XF86XK_KbdBrightnessUp0x1008FF05 /* Keyboards may be lit */ +#define XF86XK_KbdBrightnessDown 0x1008FF06 /* Keyboards may be lit */ +#define XF86XK_MonBrightnessCycle 0x1008FF07 /* Monitor/panel brightness */ /* * Keys found on some "Internet" keyboards. -- 2.11.0 Gentle ping. Any additional information for this patch is required? No extra info required. Just waiting for someone to get around to it. I needed to do some XF86keysym.h myself anyways, so I've taken a look and this looks good to me: Reviewed-by: Hans de Goede I've commit rights, so I've added and pushed this right away :) I've one favor to add, I'm about to submit an XF86keysym.h patch myself, can you review that please (and reply with a Reviewed-by if the patch looks good to you) ? I will Cc you on the patch. Thanks & Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)
On Sun, 20 Jan 2019 09:29:50 -0800 "Jasper St. Pierre" wrote: > Hi, > > Catching up on this thread. It's possible I missed something here, but > here's my two cents. > > Right now, the Wayland compositor sets up a "dummy" socket for the X11 > display. When a client connects, it launches Xwayland on-demand. I assume > this socket handoff is done similar to the systemd approach, where FDs are > inherited into execution context and their names passed by some convention > like LISTEN_FDS. Hi Jasper, that is correct. IIRC the fds get named via command line arguments. > Until Xwayland adds the socket to its own loop, the client is paused > anyway. So there are no race conditions here -- the race condition only > happens once Xwayland adds the socket. What if we had a special Wayland > event like "add_listen_fd", using Wayland's FD passing, which would add a > new FD to the listen loop of Xorg. With this, we can create a three-stage > initialization process: 1. Create a special "setup" FD, pass it to > add_listen_fd. 2. Run gnome-settings-daemon, xrdb, on this "setup" FD. 3. > After initialization settles, we then pass the client-activated socket > through "add_listen_fd", and the client will finish the handshake process. That is very much the idea I presented, but I didn't specify how to pass fds to Xwayland after its start-up. > The implementation difficulty here is passing the special setup FD to > clients -- we would have to modify Xlib to allow connecting to an X11 > socket by FD (using something like xcb_connect_to_fd), and we would have to > ensure that this all inherits to children correctly if > gnome-settings-daemon needs to launch clients during setup (I think glib > forces O_CLOEXEC before spawning children now -- oops). But FD passing for > initialization is already "the right way" to do things in a systemd world, > so it's probably something investing in. > > A quick and dirty prototype of this that wouldn't require FD passing could > simply use DISPLAY=:99 as the "setup display". > > Thoughts? I think the DISPLAY=:99 approach would be sufficient if someone wants to implement this. The setup socket has no special meaning after the start-up sequence, so it could be used for normal apps as well, which means that if someone e.g. starts a panel app from the setup script, it won't hurt if that app then launches more X11 apps with the setup socket. If a Wayland compositor launches an arbitrary script to initialize Xwayland server state, the compositor could take the exit of that process to signify the setup from the script is complete. The compositor could even launch the script only after its own XWM is ready. Thanks, pq pgpILBnZAs5C2.pgp Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
