Re: [Help]Question about graphics architecture for weson/wayland
On Tue, 19 Aug 2014 02:20:58 + Yang Andy williamyan...@hotmail.com wrote: My senario is that my target device do not support hardware accelerate.(do not use gpu) But i have to use EFL to develop application in wayland/weston platform. In order to achieve my task,how do i setup weston? Oh, so this was your real question. If you have a DRM kernel driver supporting KMS, use Weston's drm-backend but pass --use-pixman on the command line. If you do not have a DRM driver, but you do have /dev/fb0, use Weston's fbdev-backend. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]wayland-web: Fix a typo for a package dependency
On Mon, 18 Aug 2014 09:40:28 -0700 Bill Spitzak spit...@gmail.com wrote: Yes that looks right. There is nothing called libegl- but plenty called libegl1-* so I think that is the correct package name. Sorry I kept forgetting to test this on the mint machine but online searches seem to show this is correct. On 08/18/2014 01:17 AM, Pekka Paalanen wrote: On Wed, 13 Aug 2014 23:07:19 +0530 Seedo Eldho Paul seedoeldhop...@gmail.com wrote: The package 'libegl-mesa-dev' should be 'libegl1-mesa-dev' Signed-off-by: Seedo Eldho Paul seedoeldhop...@gmail.com --- mint17.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mint17.html b/mint17.html index 3de8857..173e2f4 100644 --- a/mint17.html +++ b/mint17.html @@ -52,7 +52,7 @@ cd .. span class=comment# weston:/span -apt install libegl-mesa-dev libgles2-mesa-dev libxcursor-dev libcairo2-dev \ +apt install libegl1-mesa-dev libgles2-mesa-dev libxcursor-dev libcairo2-dev \ libxcb-composite0-dev libgbm-dev libxkbcommon-dev libjpeg8-dev \ libpam0g-dev Bill, do you agree? Ok, pushed and published. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
On Mon, Aug 18, 2014 at 02:35:49PM +0300, Pekka Paalanen wrote: Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? I know the review process has been lagging behind badly, and we probably won't see e.g. IVI-shell merged for 1.6, but I try to do what I can. What major features have been forgotten on the mailing list unmerged, that you would like to see included in 1.6? I can't promise anything, and I know at least none of my new features (Presentation extension, new repaint scheduling algorithm, repaint timeline logging, DRM universal planes nuclear pageflip support, linux_dmabuf protocol sketch, and some smaller things) brewing in my personal 'next' branch will not make it. Obviously a stable first version of xdg_shell would be great to see in 1.6, but we shall see if we can beat it into shape in time. When I reviewed the XML spec not long ago, it was close but not ready in my opinion. When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland repository and it will be installed, but all build-time users of it must generate their own wrappers with wayland-scanner or equivalent. This means that libwayland-client will not contain any xdg_shell symbols or headers pre-generated. I asked Kristian and he was ok with this plan, and I have also talked a little on #wayland-devel, that maybe this would be a good idea. If this turns out a bad idea, we can always fix it later. Doing it the other way around would be near impossible. Should we make libinput the default for 1.6, so that in 1.7 we can remove the old input code, or is libinput API still too much in flux? I don't think it'll change much and Jonas and I have been talking about declaring it stable soon anyway. I've got two more changes that are somewhat urgent, both would be additive. So yes, I think switching to libinput by default would be good. Cheers, Peter Also, it was said that 1.5.1 should have come out in a few weeks and it has been 3 months now. I will try and check the patches already in 'master' of both Wayland and Weston and pick them to the 1.5 branches, but if you know of patches that should be in stable, especially ones without review or not in 'master', let me know and I try do something. My selection, especially for Wayland, will probably be very conservative, though, as my priority is 1.6. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Help]Question about graphics architecture for weson/wayland
Hi Pekka Thank you very much for your reply. If you have a DRM kernel driver supporting KMS, use Weston's drm-backend but pass --use-pixman on the command line. DRM kernel driver is for display device? Not for GPU? In other words,i can use drm-backend even though i have no GPU device. Andy Date: Tue, 19 Aug 2014 09:44:14 +0300 From: ppaala...@gmail.com To: williamyan...@hotmail.com CC: ras...@rasterman.com; wayland-devel@lists.freedesktop.org Subject: Re: [Help]Question about graphics architecture for weson/wayland On Tue, 19 Aug 2014 02:20:58 + Yang Andy williamyan...@hotmail.com wrote: My senario is that my target device do not support hardware accelerate.(do not use gpu) But i have to use EFL to develop application in wayland/weston platform. In order to achieve my task,how do i setup weston? Oh, so this was your real question. If you have a DRM kernel driver supporting KMS, use Weston's drm-backend but pass --use-pixman on the command line. If you do not have a DRM driver, but you do have /dev/fb0, use Weston's fbdev-backend. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: allow weird multitouch device without slots
On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote:
HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical
Desktop® 2.20 (connected to USB and identified as vendor 0x45e, product
0xe3, version 0x111) is reported as supporting EV_ABS event with ABS_MT_SLOT
code, but nevertheless libevdev_get_num_slots returns -1.
yeah, that's intentional. libevdev detects those devices (through guesswork,
but still...) and returns -1 as slot number.
Furthermore, all connected devices (mouse and keyboard) don't produce any
EV_ABS events for that HID Mouse device in tests with evtest.
Before this fix mouse didn't work in Weston (but worked in X.Org).
As partially explained by LKML message [1] (Message-Id [2]):
The root of the problem comes from hid-input, which maps unknown axis
to ABS_MISC. However, when an event code is already in use, hid-input
uses the one after, leading to uses of ABS_MISC + N, where N is the
number of unknown axis.
We are encountering a problem with the multitouch protocol here because
if a device has more than 7 unknown axis (which is the case for the PS3
Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT and
beyond.
[1] https://lkml.org/lkml/2013/11/20/515
[2] 1384983141-31019-1-git-send-email-benjamin.tissoi...@redhat.com
Signed-off-by: Leonid Borisenko leo.borise...@gmail.com
---
src/evdev.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index a125510..d6a14b7 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -144,7 +144,7 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
pointer_notify_motion(base, time, motion.dx, motion.dy);
break;
case EVDEV_ABSOLUTE_MT_DOWN:
- if (!(device-seat_caps EVDEV_DEVICE_TOUCH))
+ if (slot == -1 || !(device-seat_caps EVDEV_DEVICE_TOUCH))
break;
if (device-mt.slots[slot].seat_slot != -1) {
@@ -167,7 +167,7 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
touch_notify_touch_down(base, time, slot, seat_slot, x, y);
break;
case EVDEV_ABSOLUTE_MT_MOTION:
- if (!(device-seat_caps EVDEV_DEVICE_TOUCH))
+ if (slot == -1 || !(device-seat_caps EVDEV_DEVICE_TOUCH))
break;
seat_slot = device-mt.slots[slot].seat_slot;
@@ -180,7 +180,7 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
touch_notify_touch_motion(base, time, slot, seat_slot, x, y);
break;
case EVDEV_ABSOLUTE_MT_UP:
- if (!(device-seat_caps EVDEV_DEVICE_TOUCH))
+ if (slot == -1 || !(device-seat_caps EVDEV_DEVICE_TOUCH))
break;
seat_slot = device-mt.slots[slot].seat_slot;
@@ -680,6 +680,16 @@ evdev_configure_device(struct evdev_device *device)
active_slot = libevdev_get_current_slot(evdev);
}
+ if (num_slots = 0) {
+ log_bug_kernel(libinput,
+multitouch input device %s
+has %s slots\n,
+device-devnode,
+num_slots == 0 ? 0 : no);
+ num_slots = 0;
+ active_slot = -1;
+ }
+
so, as I said above the libevdev behaviour is intentional and our indicator
that this isn't a MT device after all. We should integrate that knowledge
better so that we don't label a device as touch device when it isn't, and so
that we process events from those axes as normal ABS events instead of MT
events.
Cheers,
Peter
slots = calloc(num_slots, sizeof(struct mt_slot));
if (!slots)
return -1;
--
2.1.0.rc1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: define the concept of wl_surface role
On Mon, 18 Aug 2014 10:32:28 -0400 Jasper St. Pierre jstpie...@mecheye.net wrote: On Mon, Aug 18, 2014 at 10:14 AM, Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. Thanks for this. I was going to add it in the Publican docs, but those are significantly out of date and I spent more time laughing at them than writing things in them. We should fix that. :( Yeah... Looks good overall. I'm going to be a terrible person and nitpick your grammar. Sorry about that in advance! Ha! Good that someone cares about that once in a while. :-) Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..39af61f 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,24 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does not + know where, when or how to present it. The role is the purpose of a + wl_surface. Examples of roles are a cursor for a pointer, a drag icon, + a sub-surface, and a window as defined by a shell protocol. I'd give more concrete examples. Examples of surface roles include the pointer icon (as set by wl_pointer.set_cursor), a drag icon (as set by wl_data_device.start_drag), ... I actually though of that but didn't bother, will add. + A surface can have only one role at a time. Initially a wl_surface + does not have a role. Once a role is set, it can never be set to a + different role again. There is an important clarification here. If I have two surfaces like pointer cursor, I-beam cursor, I can call wl_pointer.set_cursor on either of them in succession. I could imagine someone being confused that the pointer icon role is a singleton, and when the I-beam cursor gains it, the pointer cursor loses it, and she might think that you would have to create a new wl_surface since it's illegal to set the wl_pointer.set_cursor role on the pointer cursor surface again. Hmm, I thought the different was enough to say that. Roles are not singletons either. What we're trying to do is prevent surface reuse, so you can't transform something that was once a pointer cursor into a wl_subsurface or anything like that. Exactly. I'm not really sure how to describe this, though. I'm not too happy with this, but it's the best I came up with. A surface can only have one role at a time. When you first make a request to set a surface's role, the surface can then only have that role forever, even if it loses the role. For instance, if somebody sets the 'subsurface' role on a wl_surface, then it can only ever be a subsurface, even if you destroy the associated wl_subsurface object We should probably describe the concept of losing the role from e.g. wl_subsurface.destroy, wl_pointer.set_cursor above. I'll think about it. + A role is set by a request in another interface than wl_surface + itself. The protocol specification of the other interface + defines, that the request gives a specific role to a wl_surface. + Often, this request also creates a new protocol object, that + represents the role and extends the interface to the wl_surface. + If such a new protocol object is created, clients are + recommended to destroy it before they destroy the wl_surface. + Whether destroying the wl_surface first is legal, depends on the + protocol interface related to the role. I know you're a non-native speaker, so I won't bash your grammar in-depth. I'll just offer a replacement paragraph with everything fixed up. I'm also going to strengthen up the wording here a bit. Surface roles are set by requests in other interfaces such as wl_pointer.set_cursor. The request should explicitly mention that this request gives a role to a wl_surface. Often, this request also creates a new protocol object that represents the role and adds additional functionality to wl_surface. When clients want to destroy a surface, they must destroy this 'role object' before the wl_surface, except when specified otherwise. Okay, that is also compatible with both wl_subsurface and wl_shell_surface. We should also change the description of wl_subsurface to say that destroying the wl_surface before the role object is an exception to this rule,
Re: [Help]Question about graphics architecture for weson/wayland
On Tue, 19 Aug 2014 06:59:22 + Yang Andy williamyan...@hotmail.com said: Hi Pekka Thank you very much for your reply. If you have a DRM kernel driver supporting KMS, use Weston's drm-backend but pass --use-pixman on the command line. DRM kernel driver is for display device? Not for GPU? In other words,i can use drm-backend even though i have no GPU device. you may not have a drm driver for your hardware, but nothing stops you having fdrm and kms drivers even without a 3d gpu. you may havd 2d accel hardware that you want to manage or just simply buffer allocation/management (a lot of older hardware requires display buffers to be in linear/physical (not virtual) memory and thus requires a specialized allocator. some requires it to be in specific physical memory ranges (an older soc i know requires all gfx buffers for display and 2d accel to be inside the first physical 16mb of ram - on even older hardware before my linux days all gfx primitives, sprites, cursors, audio data, fb scanout control commands and floppy disk i/o data had to reside in the same 512kb and if it didn't it was the cpu's job to get it to/from there). if clients software rendered, but used drm buffers to render into, then it might be possible for the compositor (eg weston) if it knows it can, to program hardware layers or fbs to point directly to these buffers to scan-out from. this is how you get truly zero-copy display/output, but it would require that client uses drm directly to allocate buffers, use software to render (or whatever it likes actually), then sends compositor drm buffers. as such this is on a eventually we will do this plan for efl, but as it is not easy to support drm in a universal way to allocate buffers for scanout/display (not the last time i looked), we've got that on the back-burner. if one day there are api's we could use where we can allocate drm buffers an d ensure they are linear (or of a specific format) or query them for the layouts we do support (tiled vs linear), and can request properties on allocation - eg can scan out can be used as pointer can be used as texture etc. then that'd be awesome and we'd use it for our software rendering (and have a wayland_software_drm engine or something - or maybe make the shm engine detect this if it is available and auto use if it works). but we don't have that today because last i looked.. no such thing exists that we can use - someone correct me if something has changed... please! :) Andy Date: Tue, 19 Aug 2014 09:44:14 +0300 From: ppaala...@gmail.com To: williamyan...@hotmail.com CC: ras...@rasterman.com; wayland-devel@lists.freedesktop.org Subject: Re: [Help]Question about graphics architecture for weson/wayland On Tue, 19 Aug 2014 02:20:58 + Yang Andy williamyan...@hotmail.com wrote: My senario is that my target device do not support hardware accelerate.(do not use gpu) But i have to use EFL to develop application in wayland/weston platform. In order to achieve my task,how do i setup weston? Oh, so this was your real question. If you have a DRM kernel driver supporting KMS, use Weston's drm-backend but pass --use-pixman on the command line. If you do not have a DRM driver, but you do have /dev/fb0, use Weston's fbdev-backend. Thanks, pq -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v2] protocol: define the concept of wl_surface role
From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. + + Surface roles are set by requests in other interfaces such as + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: The road to Wayland/Weston 1.6 and 1.5.1
-Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen Sent: Monday, August 18, 2014 8:36 PM To: wayland-devel@lists.freedesktop.org; k...@bitplanet.net Cc: Jasper St. Pierre; U. Artie Eoff Subject: The road to Wayland/Weston 1.6 and 1.5.1 Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? I know the review process has been lagging behind badly, and we probably won't see e.g. IVI-shell merged for 1.6, but I try to do what I can. What major features have been forgotten on the mailing list unmerged, that you would like to see included in 1.6? [ntanibata] Hi pq, Thank you for notification. Patches of ivi-shell were improved with your comment and the latest patch set is sent to the mailing list. http://lists.freedesktop.org/archives/wayland-devel/2014-June/015616.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015968.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015969.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015970.htm l I will try to verify them on Trankyo, Manuel, provides them in his github for trial as well: https://github.com/Tarnyko/weston-ivi-shell These ones are reviewed in upstream branch of TIZEN gerrit and verified. This would be good opportunity to merge them to 1.6. I am also working enabling ivi-shell support with efl and Qt, getting help with Manuel and his colleges. BR, Nobuhiko Tanibata I can't promise anything, and I know at least none of my new features (Presentation extension, new repaint scheduling algorithm, repaint timeline logging, DRM universal planes nuclear pageflip support, linux_dmabuf protocol sketch, and some smaller things) brewing in my personal 'next' branch will not make it. Obviously a stable first version of xdg_shell would be great to see in 1.6, but we shall see if we can beat it into shape in time. When I reviewed the XML spec not long ago, it was close but not ready in my opinion. When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland repository and it will be installed, but all build-time users of it must generate their own wrappers with wayland-scanner or equivalent. This means that libwayland-client will not contain any xdg_shell symbols or headers pre-generated. I asked Kristian and he was ok with this plan, and I have also talked a little on #wayland-devel, that maybe this would be a good idea. If this turns out a bad idea, we can always fix it later. Doing it the other way around would be near impossible. Should we make libinput the default for 1.6, so that in 1.7 we can remove the old input code, or is libinput API still too much in flux? Also, it was said that 1.5.1 should have come out in a few weeks and it has been 3 months now. I will try and check the patches already in 'master' of both Wayland and Weston and pick them to the 1.5 branches, but if you know of patches that should be in stable, especially ones without review or not in 'master', let me know and I try do something. My selection, especially for Wayland, will probably be very conservative, though, as my priority is 1.6. Thanks, pq [1] http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html ___ 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: The road to Wayland/Weston 1.6 and 1.5.1
On Tue, 19 Aug 2014 16:38:42 +0900 Tanibata, Nobuhiko \(ADITJ/SWG\) ntanib...@jp.adit-jv.com wrote: -Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen Sent: Monday, August 18, 2014 8:36 PM To: wayland-devel@lists.freedesktop.org; k...@bitplanet.net Cc: Jasper St. Pierre; U. Artie Eoff Subject: The road to Wayland/Weston 1.6 and 1.5.1 Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? I know the review process has been lagging behind badly, and we probably won't see e.g. IVI-shell merged for 1.6, but I try to do what I can. What major features have been forgotten on the mailing list unmerged, that you would like to see included in 1.6? [ntanibata] Hi pq, Thank you for notification. Patches of ivi-shell were improved with your comment and the latest patch set is sent to the mailing list. http://lists.freedesktop.org/archives/wayland-devel/2014-June/015616.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015968.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015969.htm l http://lists.freedesktop.org/archives/wayland-devel/2014-July/015970.htm l I will try to verify them on Trankyo, Manuel, provides them in his github for trial as well: https://github.com/Tarnyko/weston-ivi-shell These ones are reviewed in upstream branch of TIZEN gerrit and verified. This would be good opportunity to merge them to 1.6. I am also working enabling ivi-shell support with efl and Qt, getting help with Manuel and his colleges. Thanks for keeping up. For the record, I am deliberately keeping your IVI-shell comments and patches marked in my inbox with the hope that one day I get back to it. :-) I think there are still some things that need fixing, but my review has to wait as I need to prioritize. Sorry. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. + + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: Surface roles are given by ... ---^ Thanks, pq + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] V2: load_image always prints a message on failure if filename is not empty
On Mon, 11 Aug 2014 14:28:38 -0700
Bill Spitzak spit...@gmail.com wrote:
Small change to remove the trailing whitespace error.
It was rather inconsistent before. This may help users figure out why
backgrounds and icons don't show up. A better api where the error can
be queried might be nice, but this seems sufficient for current Weston use.
---
clients/image.c |1 -
shared/image-loader.c | 11 +--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/clients/image.c b/clients/image.c
index 573117c..aee8112 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -373,7 +373,6 @@ image_create(struct display *display, const char
*filename,
image-image = load_cairo_surface(filename);
if (!image-image) {
- fprintf(stderr, could not find the image %s!\n, b);
This is an unrelated change, and needs to be in a different patch.
free(image-filename);
free(image);
return NULL;
diff --git a/shared/image-loader.c b/shared/image-loader.c
index 35dadd3..f04fb48 100644
--- a/shared/image-loader.c
+++ b/shared/image-loader.c
@@ -23,6 +23,7 @@
#include config.h
+#include errno.h
#include stdlib.h
#include stdio.h
#include string.h
@@ -374,12 +375,15 @@ load_image(const char *filename)
FILE *fp;
unsigned int i;
+ if (! filename || ! *filename) return NULL;
Extra spaces, needs new line for 'return'.
+
fp = fopen(filename, rb);
- if (fp == NULL)
- return NULL;
+ if (fp == NULL) goto ERROR;
Needs new line for 'goto'.
if (fread(header, sizeof header, 1, fp) != 1) {
fclose(fp);
+ ERROR:
Jump into a block? Looks nasty, usually we do this like
return ...;
foofoo:
fclose();
foobar:
fprintf(...);
return NULL;
}
+ fprintf(stderr, %s: %s\n, filename, strerror(errno));
return NULL;
}
@@ -399,6 +403,9 @@ load_image(const char *filename)
0x%02x 0x%02x 0x%02x 0x%02x\n,
filename, header[0], header[1], header[2], header[3]);
image = NULL;
+ } else if (!image) {
+ /* load probably printed something, but just in case */
+ fprintf(stderr, error reading image file %s!\n, filename);
}
return image;
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 01/12] Fixes to parse_options
On Fri, 8 Aug 2014 12:59:50 -0700
Bill Spitzak spit...@gmail.com wrote:
Fail on malformed numbers, such as --width=100mm
Good.
Fail on = after booleans, such as --flag=false
Okay.
Multiple single-letter booleans in one switch allowed, ie
-xyz is the same as -x -y -z. For wayland modules they all have
to belong to the same module.
This was not accepted before, right? It is confusing that one needs to
know that they are from the same module, so I'd rather just not accept
combined single letter booleans at all.
Previous version could use text after the null at the end of
an argv entry. Now requires the = sign.
What does this mean? I mean, how could one have ever used the old
behaviour? Nothing comes to my mind, so I suppose that is ok.
There are some style issues. First is the patch subject, it should be
prefixed with the component the patch is touching. To get a feeling
what the components are, look at the git-log of the file your are
changing, and there should be a pattern.
Though, I see that option-parser.c doesn't really have any pattern. Oh
well, shared: should do then.
More style issues below.
---
shared/option-parser.c | 82
+++-
1 file changed, 53 insertions(+), 29 deletions(-)
diff --git a/shared/option-parser.c b/shared/option-parser.c
index c00349a..22bcf2f 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -30,53 +30,77 @@
#include config-parser.h
-static void
+static int
handle_option(const struct weston_option *option, char *value)
{
+ char* p;
Need empty line between declarations and code.
switch (option-type) {
case WESTON_OPTION_INTEGER:
- * (int32_t *) option-data = strtol(value, NULL, 0);
- return;
+ * (int32_t *) option-data = strtol(value, p, 0);
+ return p value !*p;
Took me a couple of times to read this return statement.
How about:
return *value != '\0' *p == '\0';
Just a suggestion, doesn't matter.
case WESTON_OPTION_UNSIGNED_INTEGER:
- * (uint32_t *) option-data = strtoul(value, NULL, 0);
- return;
+ * (uint32_t *) option-data = strtoul(value, p, 0);
+ return p value !*p;
case WESTON_OPTION_STRING:
* (char **) option-data = strdup(value);
- return;
- case WESTON_OPTION_BOOLEAN:
- * (int32_t *) option-data = 1;
- return;
+ return 1;
default:
assert(0);
}
}
+static int
+long_option(const struct weston_option *options, int count, char* arg)
+{
+ int k, len;
Need empty line between declarations and code.
+ for (k = 0; k count; k++) {
+ if (! options[k].name) continue;
No space after in (! options[k].name).
'continue' should be on a new line
+ len = strlen(options[k].name);
+ if (strncmp(options[k].name, arg+2, len) != 0) continue;
add spaces: arg + 2
'continue' should be on a new line
+ if (options[k].type == WESTON_OPTION_BOOLEAN) {
+ if (! arg[len+2]) {
Extra space.
+ * (int32_t *) options[k].data = 1;
+ return 1;
+ }
+ } else if (arg[len+2] == '=') {
spaces: len + 2
+ return handle_option(options+k, arg+len+3);
spaces: options + k, arg + len + 3
+ }
+ }
+ return 0;
+}
+
+static int
+short_option(const struct weston_option *options, int count, char* arg)
+{
+ int i, k;
Need empty line between declarations and code.
+ for (i = 1; arg[i]; i++) {
+ for (k = 0; ; k++) {
+ if (k = count) return 0;
'return' to a new line.
+ if (options[k].short_name == arg[i]) break;
'break' to a new line.
+ }
+ if (options[k].type == WESTON_OPTION_BOOLEAN)
+ * (int32_t *) options[k].data = 1;
+ else
+ return handle_option(options+k, arg+i+1);
missing spaces
+ }
+ return arg[1]; /* error on just '-' */
Implicit cast to a boolean is kind of surprising, a comparison would
be more obvious:
return arg[1] != '\0';
Or better yet, just exit the function in the first lines, if arg[1] ==
'\0'.
+}
+
+
int
parse_options(const struct weston_option *options,
int count, int *argc, char *argv[])
{
- int i, j, k, len = 0;
-
+ int i, j;
Need empty line between declarations and code.
for (i = 1, j = 1; i *argc; i++) {
- for (k = 0; k count; k++) {
- if (options[k].name)
- len = strlen(options[k].name);
- if (options[k].name
- argv[i][0] == '-'
- argv[i][1] == '-'
-
Re: [PATCH] Fixes to parse_options, help info from display
On Fri, 8 Aug 2014 12:59:49 -0700 Bill Spitzak spit...@gmail.com wrote: These are a series of changes, you can pick and choose from them if you don't like them all. There are fixes to the parser so that x=5mm and bool=false and other constucts are errors rather than doing unintuitive things. Also I tried to get most of the weston demo programs to print some help if -h is given or if there is an error in the command line. The eventdemo one in particular, since the web page for building claims --help will give you some help. Note this is just done quickly without extensive rewrite, so in most cases it does not distinguish -h from errors and returns an error code in both cases. I don't think it is necessary to complicate the demo programs more than this. Hi, comments on the patches I did not apply have already been sent: 1, 12v2. Patches 7 and 8 I amended to fix minor style issues. Patch 2 should really have been split into two, a separate one to fix the erroneous -0 option, but I let it in. Patches 2-11 pushed. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cliptest: Avoid use of uninitialized memory when regions don't intersect
On Mon, 18 Aug 2014 16:13:41 -0500
Derek Foreman der...@osg.samsung.com wrote:
Prevent attempting to draw the intersection polygon when it contains no
vertices.
Signed-off-by: Derek Foreman der...@osg.samsung.com
---
clients/cliptest.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/clients/cliptest.c b/clients/cliptest.c
index a1928f4..dd0ea5c 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -570,12 +570,14 @@ draw_geometry(cairo_t *cr, struct weston_surface
*surface,
Hi Derek,
looks like your email client decided to wrap the patch and it didn't
apply, so I fixed it and applied.
cairo_set_source_rgba(cr, 0.0, 0.0, 1.0, 0.4);
cairo_fill(cr);
- draw_polygon_closed(cr, ex, ey, n);
- cairo_set_source_rgb(cr, 0.0, 1.0, 0.0);
- cairo_stroke(cr);
+ if (n) {
+ draw_polygon_closed(cr, ex, ey, n);
+ cairo_set_source_rgb(cr, 0.0, 1.0, 0.0);
+ cairo_stroke(cr);
- cairo_set_source_rgba(cr, 0.0, 1.0, 0.0, 0.5);
- draw_polygon_labels(cr, ex, ey, n);
+ cairo_set_source_rgba(cr, 0.0, 1.0, 0.0, 0.5);
+ draw_polygon_labels(cr, ex, ey, n);
+ }
}
static void
Looks good, pushed.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Wed, 6 Aug 2014 19:07:50 -0400 Stephen Chandler Paul thatsly...@gmail.com wrote: Hi! As some of you have been aware, I have been working on implementing tablet ssupport in libinput, the wayland protocol and weston. This patchset adds basic tablet support to weston, along with support in the shell and the window manager. It should be noted that these patches rely on one of the earlier patches to libinput that I posted on the mailing list: tablet: Add libinput_tablet_has_axis(), along with the tablet-support branch in the git repository for libinput. As of right now, the following things are still missing/haven't been finished yet: * Tablet objects don't ever send a removed event, right now it's up to the clients to free the resources for each tool object. * Tablet tool objects should be separate for each tablet connected that doesn't report serial numbers. Right now tablet objects are shared by all tablets connected to the system unconditionally. * The tablet cursor disappears occasionally when moving a window and causing the mouse pointer to change images, but reappears the next time a client sets a cursor image. * weston-flower can crash the shell for some reason. It seems that if a tablet is turned on, and the first surface the tool comes into focus on belongs to a weston-flower instance, the desktop-shell runs into an error and exits. I haven't noticed this with anything other then weston-flower though. * Held down buttons are released when the tool changes focus from one surface to another, instead of being held down until they're released. * Some of the declarations for structs in my code might need to be moved around, I'm not sure what the expected guidelines for this in weston's code are though. * A surface argument needs to be added to the proximity_out event, so we can tell if the tablet tool is leaving proximity to switch focus to another surface, or if it's just exiting proximity. Review/critique would be appreciated, thank you! ^^ Cheers, Lyude Stephen Chandler Paul (19): tablet: Add XML for wl_tablet and wl_tablet_manager tablet: Add initial tablet support to weston client: Add support for handling motion events in toytoolkit client: Add support for handling proximity_in/out events in libtoytoolkit tablet: Add support for setting/changing the tablet cursor in weston client: Add tablet cursor support into libtoytoolkit tablet: Add support for tablet tool objects client: Add support for tool objects in libtoytoolkit client: Add support for tablet cursor motion to window frames in libtoytoolkit tablet: Add support for button presses to weston client: Add support for handling button presses to libtoytoolkit tablet: Add support for up/down events to weston client: Add up/down event support into libtoytoolkit tablet: Add support for moving windows around using the stylus tablet: Add support for reporting pressure, distance, and tilt in weston client: Add support for pressure, distance, and tilt into libtoytoolkit tablet: Add tablet support to the top panel of the desktop shell tablet: Add binding to activate surfaces using the tablet tool tablet: Add demo application for tablets .gitignore | 1 + Makefile.am | 23 +- clients/desktop-shell.c | 55 clients/tablet.c| 341 clients/window.c| 607 clients/window.h| 102 ++ desktop-shell/shell.c | 282 + protocol/wayland-tablet.xml | 310 +++ shared/cairo-util.h | 4 + shared/frame.c | 38 +++ src/bindings.c | 37 +++ src/compositor.c| 1 + src/compositor.h| 171 ++ src/input.c | 736 src/libinput-device.c | 317 +++ src/libinput-device.h | 4 +- 16 files changed, 3024 insertions(+), 5 deletions(-) create mode 100644 clients/tablet.c create mode 100644 protocol/wayland-tablet.xml Hi, just a heads-up, do I get the right impression that this is not yet in a shape to merge into Weston, so won't be included in 1.6? Could an input person review this and suggest whether this should in his opinion get merged for 1.6 and is it reasonable to assume, that all the remaining known bugs can be sufficiently fixed within the couple of weeks or so that our alpha and RC phase lasts? I still haven't read the latest protocol discussion thread, so I'm not sure where the design is atm. Personally I cannot even test this, since I don't have a tablet device here. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] configure.ac: use libinput by default
From: Pekka Paalanen pekka.paala...@collabora.co.uk Libinput is stabilizing soon, so let's flip the default switch now. The old input code will still be carried as an option for a while. Cc: Peter Hutterer peter.hutte...@who-t.net Cc: Jonas Ådahl jad...@gmail.com Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 354db14..bc5c88a 100644 --- a/configure.ac +++ b/configure.ac @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then fi -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, - enable_libinput_backend=no) +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, + enable_libinput_backend=yes) AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend = xyes]) if test x$enable_libinput_backend = xyes; then AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input device backend]) -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On 18 August 2014 12:23, Marek Chalupa mchqwe...@gmail.com wrote:
Hi,
thanks for reviewing.
The failure you got is not introduced by this patch, I reported it some
time ago here:
https://bugs.freedesktop.org/show_bug.cgi?id=80594
I put a patch for this bug into bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=80594
On 18 August 2014 12:18, Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 12 Aug 2014 11:35:07 +0200
Marek Chalupa mchqwe...@gmail.com wrote:
Test if when we get a signal, all signal sources for that signal
get dispatched.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
tests/event-loop-test.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tests/event-loop-test.c b/tests/event-loop-test.c
index e327a66..1709a1a 100644
--- a/tests/event-loop-test.c
+++ b/tests/event-loop-test.c
@@ -173,6 +173,44 @@ TEST(event_loop_signal)
wl_event_loop_destroy(loop);
}
+TEST(event_loop_multiple_same_signals)
+{
+ struct wl_event_loop *loop = wl_event_loop_create();
+ struct wl_event_source *s1, *s2;
+ int calls_no = 0;
+ int i;
+
+ s1 = wl_event_loop_add_signal(loop, SIGUSR1,
+ signal_callback, calls_no);
+ assert(s1);
+
+ s2 = wl_event_loop_add_signal(loop, SIGUSR1,
+ signal_callback, calls_no);
+ assert(s2);
+
+ assert(wl_event_loop_dispatch(loop, 0) == 0);
+ assert(!calls_no);
+
+ /* Try it more times */
+ for (i = 0; i 5; ++i) {
+ calls_no = 0;
+ kill(getpid(), SIGUSR1);
+ assert(wl_event_loop_dispatch(loop, 0) == 0);
+ assert(calls_no == 2);
+ }
+
+ wl_event_source_remove(s1);
+
+ /* Try it again with one source */
+ calls_no = 0;
+ kill(getpid(), SIGUSR1);
+ assert(wl_event_loop_dispatch(loop, 0) == 0);
+ assert(calls_no == 1);
+
+ wl_event_source_remove(s2);
+
+ wl_event_loop_destroy(loop);
+}
static int
timer_callback(void *data)
The first two of the three patches pushed. We have an explicit configure
check from SFD_CLOEXEC, but I suppose we don't need to add one for
SFD_NONBLOCK, because the two were supposedly introduced at the same
time in glibc.
I did not push this third patch, because in my testing, the test failed
once. It was very hard, but I did manage to trigger it a second time
too, by having lots of CPU and IO load on the machine and running the
test in loop until it failed:
test event_loop_destroy: exit status 0, pass.
event-loop-test: tests/event-loop-test.c:298: event_loop_timer_updates:
Assertion `context.count == 2' failed.
test event_loop_timer_updates:signal 6, fail.
test event_loop_timer:exit status 0, pass.
test event_loop_multiple_same_signals:exit status 0, pass.
test event_loop_signal: exit status 0, pass.
test event_loop_free_source_with_data:exit status 0, pass.
test event_loop_post_dispatch_check: exit status 0, pass.
7 tests, 6 pass, 1 fail
I would like to see some fix on that, even if only theoretical, before
I push this one.
Or an ack from someone else that we should just push this and wait for
the fallout if any.
Thanks,
pq
Regards,
Marek
Regards,
Marek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue
On Wed, 16 Jul 2014 11:13:06 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-07-15 20:39 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Tuesday, July 15, 2014, Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-07-14 22:31 GMT+03:00 Jason Ekstrand ja...@jlekstrand.net:
Guilio,
Would it be better to name it wl_event_queue_roundtrip and just have it
take
the wl_event_queue? I guess it is sort-of a wl_display operation, but
you
could argue it either way. Thoughts?
You have a point here, it makes more sense.
TBH I'd rather steer clear of that nomenclature, since the 'queue' in an
immediate request context implies delayed dispatch, rather than on a queue.
I didn't realize you could read it as queue a roundtrip on a
wl_event. I think that the meaning is quite obvious once you know
that there is a wl_event_queue type in Wayland.
Hi,
hm, that's a tricky one. Yes, the name wl_event_queue_roundtrip() is
confusing when out of context, but as the argument is a wl_event_queue,
that name is the logical and unfortunate result.
Another problem with wl_display_roundtrip_queue() is that it gets both
wl_display and wl_event_queue as arguments. Therefore the function
would need to check that the wl_event_queue indeed belongs to the given
wl_display. It's just a thing one can get wrong, and it has no benefits
that I see.
wl_display_roundtrip_queue() taking only wl_event_queue as an argument
would be strange, because the name implies a wl_display method.
(Up until this point, I would have agreed with Giulio and Jason...)
But, now I see, that we already have:
int wl_display_dispatch_queue(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_dispatch_queue_pending(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_prepare_read_queue(struct wl_display *display,
struct wl_event_queue *queue);
So there is precendent, that redundant arguments are ok, and
wl_display_roundtrip_queue() would indeed follow the existing scheme.
Btw. I do not see anywhere, where the libwayland-client code would be
checking that the wl_display and the wl_event_queue would actually be
related. Would be a good thing to add more checks to the public API
functions for that.
I think I would go with wl_display_roundtrip_queue() here. Would you
agree?
Thanks,
pq
On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo
giuliocamu...@gmail.com
wrote:
wl_display_roundtrip() works on the default queue. Add a parallel
wl_display_roundtrip_queue().
---
v3: fixed dispatch call in place of dispatch_queue
documented the queue parameter
src/wayland-client.c | 24 +---
src/wayland-client.h | 2 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index e8aab7e..d2c1b5c 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -834,15 +834,16 @@ static const struct wl_callback_listener
sync_listener = {
/** Block until all pending request are processed by the server
*
* \param display The display context object
+ * \param queue The queue on which to run the roundtrip
* \return The number of dispatched events on success or -1 on failure
*
* Blocks until the server process all currently issued requests and
- * sends out pending events on all event queues.
+ * sends out pending events on the event queue.
*
* \memberof wl_display
*/
WL_EXPORT int
-wl_display_roundtrip(struct wl_display *display)
+wl_display_roundtrip_queue(struct wl_display *display, struct
wl_event_queue *queue)
{
struct wl_callback *callback;
int done, ret = 0;
@@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display *display)
callback = wl_display_sync(display);
if (callback == NULL)
return -1;
+ wl_proxy_set_queue(callback, queue);
wl_callback_add_listener(callback, sync_listener, done);
while (!done ret = 0)
- ret = wl_display_dispatch(display);
+ ret = wl_display_dispatch_queue(display, queue);
if (ret == -1 !done)
wl_callback_destroy(callback);
@@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display *display)
return ret;
}
+/** Block until all pending request are processed by the server
+ *
+ * \param display The display context object
+ * \return The number of dispatched events on success or -1 on failure
+ *
+ * Blocks until the server process all currently issued requests and
+ * sends out pending events on the default event queue.
+ *
+ * \memberof wl_display
+ */
+WL_EXPORT int
+wl_display_roundtrip(struct wl_display *display)
+{
+
[PATCH] cliptest: Don't underrun the vertex array of empty polygons.
This silences the following warning:
clients/cliptest.c:277:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx-prev.x = src-x[src-n - 1];
Signed-off-by: Ondřej Majerech oxyd.o...@gmail.com
---
clients/cliptest.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..20b3776 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_left_edge(ctx, src-x[i], src-y[i]);
@@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_right_edge(ctx, src-x[i], src-y[i]);
@@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_top_edge(ctx, src-x[i], src-y[i]);
@@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_bottom_edge(ctx, src-x[i], src-y[i]);
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Tue, Aug 19, 2014 at 01:03:52PM +0300, Pekka Paalanen wrote: On Wed, 6 Aug 2014 19:07:50 -0400 Stephen Chandler Paul thatsly...@gmail.com wrote: Hi! As some of you have been aware, I have been working on implementing tablet ssupport in libinput, the wayland protocol and weston. This patchset adds basic tablet support to weston, along with support in the shell and the window manager. It should be noted that these patches rely on one of the earlier patches to libinput that I posted on the mailing list: tablet: Add libinput_tablet_has_axis(), along with the tablet-support branch in the git repository for libinput. As of right now, the following things are still missing/haven't been finished yet: * Tablet objects don't ever send a removed event, right now it's up to the clients to free the resources for each tool object. * Tablet tool objects should be separate for each tablet connected that doesn't report serial numbers. Right now tablet objects are shared by all tablets connected to the system unconditionally. * The tablet cursor disappears occasionally when moving a window and causing the mouse pointer to change images, but reappears the next time a client sets a cursor image. * weston-flower can crash the shell for some reason. It seems that if a tablet is turned on, and the first surface the tool comes into focus on belongs to a weston-flower instance, the desktop-shell runs into an error and exits. I haven't noticed this with anything other then weston-flower though. * Held down buttons are released when the tool changes focus from one surface to another, instead of being held down until they're released. * Some of the declarations for structs in my code might need to be moved around, I'm not sure what the expected guidelines for this in weston's code are though. * A surface argument needs to be added to the proximity_out event, so we can tell if the tablet tool is leaving proximity to switch focus to another surface, or if it's just exiting proximity. Review/critique would be appreciated, thank you! ^^ Cheers, Lyude Stephen Chandler Paul (19): tablet: Add XML for wl_tablet and wl_tablet_manager tablet: Add initial tablet support to weston client: Add support for handling motion events in toytoolkit client: Add support for handling proximity_in/out events in libtoytoolkit tablet: Add support for setting/changing the tablet cursor in weston client: Add tablet cursor support into libtoytoolkit tablet: Add support for tablet tool objects client: Add support for tool objects in libtoytoolkit client: Add support for tablet cursor motion to window frames in libtoytoolkit tablet: Add support for button presses to weston client: Add support for handling button presses to libtoytoolkit tablet: Add support for up/down events to weston client: Add up/down event support into libtoytoolkit tablet: Add support for moving windows around using the stylus tablet: Add support for reporting pressure, distance, and tilt in weston client: Add support for pressure, distance, and tilt into libtoytoolkit tablet: Add tablet support to the top panel of the desktop shell tablet: Add binding to activate surfaces using the tablet tool tablet: Add demo application for tablets .gitignore | 1 + Makefile.am | 23 +- clients/desktop-shell.c | 55 clients/tablet.c| 341 clients/window.c| 607 clients/window.h| 102 ++ desktop-shell/shell.c | 282 + protocol/wayland-tablet.xml | 310 +++ shared/cairo-util.h | 4 + shared/frame.c | 38 +++ src/bindings.c | 37 +++ src/compositor.c| 1 + src/compositor.h| 171 ++ src/input.c | 736 src/libinput-device.c | 317 +++ src/libinput-device.h | 4 +- 16 files changed, 3024 insertions(+), 5 deletions(-) create mode 100644 clients/tablet.c create mode 100644 protocol/wayland-tablet.xml Hi, just a heads-up, do I get the right impression that this is not yet in a shape to merge into Weston, so won't be included in 1.6? Yes. The libinput side of tablet support still live on a separate branch, so merging this series is not an option for 1.6 IMHO. Jonas Could an input person review this and suggest whether this should in his opinion get merged for 1.6 and is it reasonable to assume, that all the remaining known bugs can be sufficiently fixed within the couple of weeks or so that our alpha and RC phase lasts? I still haven't read the latest protocol
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On Tue, 19 Aug 2014 12:37:53 +0200 Marek Chalupa mchqwe...@gmail.com wrote: On 18 August 2014 12:23, Marek Chalupa mchqwe...@gmail.com wrote: Hi, thanks for reviewing. The failure you got is not introduced by this patch, I reported it some time ago here: https://bugs.freedesktop.org/show_bug.cgi?id=80594 I put a patch for this bug into bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80594 Hi, ok, I picked them up from bugzilla, but I would really prefer email to the list, because I can't review bugzilla attachments on the mailing list, and it is much much easier for me to apply patches from email. So the essence of the test is to get two timers fire so, that they will both be dispatched on the same wl_event_loop_dispatch() call. What it actually tests is that the timerfd handler won't get stuck because the handler that runs first modifies the second. I believe your patch should fix it, so I pushed them. I try to remember to leave a 'make check' loop running over night. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
Hi, On 19 August 2014 07:54, Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, Aug 18, 2014 at 02:35:49PM +0300, Pekka Paalanen wrote: Should we make libinput the default for 1.6, so that in 1.7 we can remove the old input code, or is libinput API still too much in flux? I don't think it'll change much and Jonas and I have been talking about declaring it stable soon anyway. I've got two more changes that are somewhat urgent, both would be additive. So yes, I think switching to libinput by default would be good. +1 from me. Even if it does still have problems, it's a damn sight better than what came before it, and I'd like to bin the latter as soon as possible. So if we can agree a sensible libinput release for dependencies, we should absolutely do this. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
Hi,
On 18 August 2014 13:14, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 18 Aug 2014 14:57:37 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-08-18 14:35 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
had these patches which I'd like to see going in:
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012589.html
This one looks pretty simple, and I can confirm the problem with
CapsLock, so yes, I'd like to take this. Could you rebase it?
This is a good start, yes. It's either that or go through the keymap state
trying to work out the modifier state to accompany the LEDs, which is
doable but a bit fiddly.
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012590.html
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012591.html
Of these two, the first needs the second to be used at all, right? The
follow-up comment is true, I would not want NumLock be on by default on
my laptop, so I think this needs more work, like you have identified.
Yes, definitely not on by default please. As for the second patch, I'm a
little hesitant to add it to X11 in particular: why should we be telling
the host server what the modifier state for the entire session (which is
larger than the nested compositor) should be?
evdev requires LEDs to be driven because in that situation, we are the
lowest-level input consumer, and thus calculate our own state (i.e. call
xkb_state_update_key). In nested environments (compositor-{x11,wayland}),
we never calculate our own state, but receive the state from the host
display server. If the host display server isn't keeping the state sent to
its clients in sync with the state of its input devices, then that's a bug.
(tl;dr: NAK)
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] tests: add one more test for event-loop signal source
On 19 August 2014 13:37, Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 12:37:53 +0200 Marek Chalupa mchqwe...@gmail.com wrote: On 18 August 2014 12:23, Marek Chalupa mchqwe...@gmail.com wrote: Hi, thanks for reviewing. The failure you got is not introduced by this patch, I reported it some time ago here: https://bugs.freedesktop.org/show_bug.cgi?id=80594 I put a patch for this bug into bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80594 Hi, ok, I picked them up from bugzilla, but I would really prefer email to the list, because I can't review bugzilla attachments on the mailing list, and it is much much easier for me to apply patches from email. Ok :) So the essence of the test is to get two timers fire so, that they will both be dispatched on the same wl_event_loop_dispatch() call. What it actually tests is that the timerfd handler won't get stuck because the handler that runs first modifies the second. Yes. I believe your patch should fix it, so I pushed them. I try to remember to leave a 'make check' loop running over night. I had it running in a loop for some time and I hope it fixed it. It was not a whole night, though :) Thanks, pq Thanks, Marek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
2014-08-19 14:50 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi,
On 18 August 2014 13:14, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 18 Aug 2014 14:57:37 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-08-18 14:35 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
had these patches which I'd like to see going in:
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012589.html
This one looks pretty simple, and I can confirm the problem with
CapsLock, so yes, I'd like to take this. Could you rebase it?
This is a good start, yes. It's either that or go through the keymap state
trying to work out the modifier state to accompany the LEDs, which is doable
but a bit fiddly.
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012590.html
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012591.html
Of these two, the first needs the second to be used at all, right? The
follow-up comment is true, I would not want NumLock be on by default on
my laptop, so I think this needs more work, like you have identified.
Yes, definitely not on by default please. As for the second patch, I'm a
little hesitant to add it to X11 in particular: why should we be telling the
host server what the modifier state for the entire session (which is larger
than the nested compositor) should be?
evdev requires LEDs to be driven because in that situation, we are the
lowest-level input consumer, and thus calculate our own state (i.e. call
xkb_state_update_key). In nested environments (compositor-{x11,wayland}), we
never calculate our own state, but receive the state from the host display
server. If the host display server isn't keeping the state sent to its
clients in sync with the state of its input devices, then that's a bug.
That makes sense, and I don't remember why i wrote that
x11_compositor_led_update() honestly.
I'll reply with a patch just adding the weston_keyboard_set_leds API,
without the X11 code.
--
Giulio
(tl;dr: NAK)
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Added destructor protocol to wl_data_device interface
From: kabeer.khan kabeer.khan@kabeer-khan.(none) This is a fix to Bug# 81745 Signed-off-by: kabeer kabeer.k...@samsung.com --- protocol/wayland.xml |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..c3a9f28 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -569,8 +569,13 @@ arg name=source type=object interface=wl_data_source allow-null=true/ arg name=serial type=uint summary=serial of the event that triggered this request/ /request - -event name=data_offer + request name=destroy type=destructor + description summary=destroy the data device +Destroy the data device. + /description +/request + + event name=data_offer description summary=introduce a new wl_data_offer The data_offer event introduces a new wl_data_offer object, which will subsequently be used in either the -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cliptest: Don't underrun the vertex array of empty polygons.
On Tue, 19 Aug 2014 13:10:55 +0200
Ondřej Majerech oxyd.o...@gmail.com wrote:
This silences the following warning:
clients/cliptest.c:277:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx-prev.x = src-x[src-n - 1];
Hi,
seems like I would need something more recent than gcc 4.6.4 to get
these warnings, right?
Do you not get these warnings from src/vertex-clipping.c too?
At minimum, could you patch both clients/cliptest.c and
src/vertex-clipping.c in the same patch, and check that the duplicated
code is identical.
An even better alternative would be to just drop the duplicate code
from cliptest.c, and make it somehow just use src/vertex-clipping.c
and .h. I'm not sure how the build system would cope with that, but
that would be excellent. So first remove duplication, then fix the
issues.
Also, I think the correct condition would be:
if (src-n 2)
return 0;
Because if a polygon has less than 2 points, it's not a polygon that
could even theoretically be clipped. The 2 points case also is
denegerate, but least it has two lines that can be clipped.
Thanks,
pq
Signed-off-by: Ondřej Majerech oxyd.o...@gmail.com
---
clients/cliptest.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..20b3776 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_left_edge(ctx, src-x[i], src-y[i]);
@@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_right_edge(ctx, src-x[i], src-y[i]);
@@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_top_edge(ctx, src-x[i], src-y[i]);
@@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const
struct polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_bottom_edge(ctx, src-x[i], src-y[i]);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cliptest: Don't underrun the vertex array of empty polygons.
On 19 August 2014 14:16, Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 19 Aug 2014 13:10:55 +0200
Ondřej Majerech oxyd.o...@gmail.com wrote:
This silences the following warning:
clients/cliptest.c:277:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx-prev.x = src-x[src-n - 1];
Hi,
seems like I would need something more recent than gcc 4.6.4 to get
these warnings, right?
I'm using GCC 4.9.1, so presumably yes. :)
Do you not get these warnings from src/vertex-clipping.c too?
Ah, yes. Fresh rebuild gives me warnings from src/vertex-clipping.c as well.
At minimum, could you patch both clients/cliptest.c and
src/vertex-clipping.c in the same patch, and check that the duplicated
code is identical.
An even better alternative would be to just drop the duplicate code
from cliptest.c, and make it somehow just use src/vertex-clipping.c
and .h. I'm not sure how the build system would cope with that, but
that would be excellent. So first remove duplication, then fix the
issues.
indeed. I'll see what I can do about the duplication.
Also, I think the correct condition would be:
if (src-n 2)
return 0;
Because if a polygon has less than 2 points, it's not a polygon that
could even theoretically be clipped. The 2 points case also is
denegerate, but least it has two lines that can be clipped.
You're right -- I was thinking more about buffers than geometry. :)
Thanks,
pq
Signed-off-by: Ondřej Majerech oxyd.o...@gmail.com
---
clients/cliptest.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..20b3776 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -287,6 +287,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_left_edge(ctx, src-x[i], src-y[i]);
@@ -303,6 +306,9 @@ clip_polygon_right(struct clip_context *ctx, const
struct polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_right_edge(ctx, src-x[i], src-y[i]);
@@ -319,6 +325,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_top_edge(ctx, src-x[i], src-y[i]);
@@ -335,6 +344,9 @@ clip_polygon_bottom(struct clip_context *ctx, const
struct polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n == 0)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_bottom_edge(ctx, src-x[i], src-y[i]);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/2] xwm: Use cursor theme and size in weston.ini
On Sun, 6 Jul 2014 11:44:57 +0800
Boyan Ding stu_...@126.com wrote:
to make it consistent with native wayland apps
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2fb65b1..f64ef94 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -38,6 +38,7 @@
#include cairo-util.h
#include compositor.h
+#include config-parser.h
#include hash.h
struct wm_size_hints {
@@ -269,22 +270,24 @@ xcb_cursor_images_load_cursor(struct weston_wm *wm,
const XcursorImages *images)
static xcb_cursor_t
xcb_cursor_library_load_cursor(struct weston_wm *wm, const char *file)
{
+ struct weston_config *config;
+ struct weston_config_section *s;
xcb_cursor_t cursor;
XcursorImages *images;
- char *v = NULL;
+ char *theme = NULL;
int size = 0;
if (!file)
return 0;
- v = getenv (XCURSOR_SIZE);
- if (v)
- size = atoi(v);
+ config = weston_config_parse(weston.ini);
+ s = weston_config_get_section(config, shell, NULL, NULL);
+ weston_config_section_get_string(s, cursor-theme, theme, NULL);
+ weston_config_section_get_int(s, cursor-size, size, 32);
+ weston_config_destroy(config);
- if (!size)
- size = 32;
-
- images = XcursorLibraryLoadImages (file, NULL, size);
+ images = XcursorLibraryLoadImages (file, theme, size);
+ free(theme);
if (!images)
return -1;
Hi,
looks ok, but could you re-spin this so that you do not call
weston_config_parse() but use the already parsed
weston_compositor::config?
For an example, see 673a889fd88a70a9308d29bd6574f7c8c67da68d.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] cairo-util: Draw solid titlebar for frames with only buttons
On Tue, 5 Aug 2014 15:22:04 +0800
Boyan Ding stu_...@126.com wrote:
Previously geometry was changed to leave space for titlebar if a frame
has only buttons but no title. This patch fixes theme_render_frame to
avoid transparent titlebar.
Signed-off-by: Boyan Ding stu_...@126.com
---
shared/cairo-util.c | 8 +---
shared/cairo-util.h | 5 -
shared/frame.c | 2 +-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index 2a33249..26286c5 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -28,6 +28,7 @@
#include string.h
#include stdio.h
#include math.h
+#include wayland-util.h
#include cairo.h
#include cairo-util.h
@@ -413,7 +414,8 @@ theme_destroy(struct theme *t)
void
theme_render_frame(struct theme *t,
cairo_t *cr, int width, int height,
-const char *title, uint32_t flags)
+const char *title, struct wl_list *buttons,
+uint32_t flags)
{
cairo_text_extents_t extents;
cairo_font_extents_t font_extents;
@@ -439,7 +441,7 @@ theme_render_frame(struct theme *t,
else
source = t-inactive_frame;
- if (title)
+ if (title || !wl_list_empty(buttons))
top_margin = t-titlebar_height;
else
top_margin = t-width;
@@ -449,7 +451,7 @@ theme_render_frame(struct theme *t,
width - margin * 2, height - margin * 2,
t-width, top_margin);
- if (title) {
+ if (title || !wl_list_empty(buttons)) {
cairo_rectangle (cr, margin + t-width, margin,
width - (margin + t-width) * 2,
t-titlebar_height - t-width);
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4493b0d..fb25c34 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -26,6 +26,8 @@
#include stdint.h
#include cairo.h
+#include wayland-util.h
+
void
surface_flush_device(cairo_surface_t *surface);
@@ -69,7 +71,8 @@ theme_set_background_source(struct theme *t, cairo_t *cr,
uint32_t flags);
void
theme_render_frame(struct theme *t,
cairo_t *cr, int width, int height,
-const char *title, uint32_t flags);
+const char *title, struct wl_list *buttons,
+uint32_t flags);
enum theme_location {
THEME_LOCATION_INTERIOR = 0,
diff --git a/shared/frame.c b/shared/frame.c
index 53f3f5f..5ea0e12 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -853,7 +853,7 @@ frame_repaint(struct frame *frame, cairo_t *cr)
cairo_save(cr);
theme_render_frame(frame-theme, cr, frame-width, frame-height,
-frame-title, flags);
+frame-title, frame-buttons, flags);
cairo_restore(cr);
wl_list_for_each(button, frame-buttons, link)
Not sure how I'd test it, but it looks okay to me... pushed.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] xwm: check whether the picked seat can be NULL
On Sun, 6 Jul 2014 11:44:58 +0800 Boyan Ding stu_...@126.com wrote: The seat picked in weston_wm_window_handle_moveresize can sometimes be NULL when it is (somehow) triggered with all buttons released. This patch checks whether the seat is NULL to avoid NULL dereference. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80837 Signed-off-by: Boyan Ding stu_...@126.com --- xwayland/window-manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c index f64ef94..6e74b89 100644 --- a/xwayland/window-manager.c +++ b/xwayland/window-manager.c @@ -1250,8 +1250,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window, struct weston_shell_interface *shell_interface = wm-server-compositor-shell_interface; - if (seat-pointer-button_count != 1 || !window-view - || seat-pointer-focus != window-view) + if (seat == NULL || seat-pointer-button_count != 1 + || !window-view || seat-pointer-focus != window-view) return; detail = client_message-data.data32[2]; Shouldn't hurt and I accidentally already pushed this. :-P I was not able to reproduce the crash without the patch, and using gnome-terminal, either. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/19] Basic tablet support in Weston
On Tue, 19 Aug 2014 13:21:54 +0200 Jonas Ådahl jad...@gmail.com wrote: On Tue, Aug 19, 2014 at 01:03:52PM +0300, Pekka Paalanen wrote: On Wed, 6 Aug 2014 19:07:50 -0400 Stephen Chandler Paul thatsly...@gmail.com wrote: Hi! As some of you have been aware, I have been working on implementing tablet ssupport in libinput, the wayland protocol and weston. This patchset adds basic tablet support to weston, along with support in the shell and the window manager. It should be noted that these patches rely on one of the earlier patches to libinput that I posted on the mailing list: tablet: Add libinput_tablet_has_axis(), along with the tablet-support branch in the git repository for libinput. As of right now, the following things are still missing/haven't been finished yet: * Tablet objects don't ever send a removed event, right now it's up to the clients to free the resources for each tool object. * Tablet tool objects should be separate for each tablet connected that doesn't report serial numbers. Right now tablet objects are shared by all tablets connected to the system unconditionally. * The tablet cursor disappears occasionally when moving a window and causing the mouse pointer to change images, but reappears the next time a client sets a cursor image. * weston-flower can crash the shell for some reason. It seems that if a tablet is turned on, and the first surface the tool comes into focus on belongs to a weston-flower instance, the desktop-shell runs into an error and exits. I haven't noticed this with anything other then weston-flower though. * Held down buttons are released when the tool changes focus from one surface to another, instead of being held down until they're released. * Some of the declarations for structs in my code might need to be moved around, I'm not sure what the expected guidelines for this in weston's code are though. * A surface argument needs to be added to the proximity_out event, so we can tell if the tablet tool is leaving proximity to switch focus to another surface, or if it's just exiting proximity. Review/critique would be appreciated, thank you! ^^ Cheers, Lyude Stephen Chandler Paul (19): tablet: Add XML for wl_tablet and wl_tablet_manager tablet: Add initial tablet support to weston client: Add support for handling motion events in toytoolkit client: Add support for handling proximity_in/out events in libtoytoolkit tablet: Add support for setting/changing the tablet cursor in weston client: Add tablet cursor support into libtoytoolkit tablet: Add support for tablet tool objects client: Add support for tool objects in libtoytoolkit client: Add support for tablet cursor motion to window frames in libtoytoolkit tablet: Add support for button presses to weston client: Add support for handling button presses to libtoytoolkit tablet: Add support for up/down events to weston client: Add up/down event support into libtoytoolkit tablet: Add support for moving windows around using the stylus tablet: Add support for reporting pressure, distance, and tilt in weston client: Add support for pressure, distance, and tilt into libtoytoolkit tablet: Add tablet support to the top panel of the desktop shell tablet: Add binding to activate surfaces using the tablet tool tablet: Add demo application for tablets .gitignore | 1 + Makefile.am | 23 +- clients/desktop-shell.c | 55 clients/tablet.c| 341 clients/window.c| 607 clients/window.h| 102 ++ desktop-shell/shell.c | 282 + protocol/wayland-tablet.xml | 310 +++ shared/cairo-util.h | 4 + shared/frame.c | 38 +++ src/bindings.c | 37 +++ src/compositor.c| 1 + src/compositor.h| 171 ++ src/input.c | 736 src/libinput-device.c | 317 +++ src/libinput-device.h | 4 +- 16 files changed, 3024 insertions(+), 5 deletions(-) create mode 100644 clients/tablet.c create mode 100644 protocol/wayland-tablet.xml Hi, just a heads-up, do I get the right impression that this is not yet in a shape to merge into Weston, so won't be included in 1.6? Yes. The libinput side of tablet support still live on a separate branch, so merging this series is not an option for 1.6 IMHO. Ok, thanks for confirming that this is one series I don't need to feel bad about. :-) - pq
Re: The road to Wayland/Weston 1.6 and 1.5.1
On Mon, 18 Aug 2014 20:55:52 +0800 Boyan Ding stu_...@126.com wrote: Hi, On Mon, 2014-08-18 at 14:35 +0300, Pekka Paalanen wrote: Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? [...] Also, it was said that 1.5.1 should have come out in a few weeks and it has been 3 months now. I will try and check the patches already in 'master' of both Wayland and Weston and pick them to the 1.5 branches, but if you know of patches that should be in stable, especially ones without review or not in 'master', let me know and I try do something. My selection, especially for Wayland, will probably be very conservative, though, as my priority is 1.6. There are two patches for xwayland part in weston that has stood for quite a while: http://lists.freedesktop.org/archives/wayland-devel/2014-July/015885.html http://lists.freedesktop.org/archives/wayland-devel/2014-July/015886.html with the first one being a little feature and the second one a simple bugfix. Also another patch that doesn't got reviewed but quite important: http://lists.freedesktop.org/archives/wayland-devel/2014-August/016307.html It should follow c4902124 and 9c5aedff in master (and also in 1.5 branch) but I left that out then. All three adressed, I think. Feel free to poke me again when I start asking about what I forgot from the stable branches. I'd like to let things live a bit in master, if at all possible. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 2/2] Don't underrun the vertex array of empty polygons
This silences the following warning:
src/vertex-clipping.c:196:22: warning: array subscript is below array
bounds [-Warray-bounds]
ctx-prev.x = src-x[src-n - 1];
Signed-off-by: Ondřej Majerech oxyd.o...@gmail.com
---
src/vertex-clipping.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/vertex-clipping.c b/src/vertex-clipping.c
index db527e1..2bb8c0a 100644
--- a/src/vertex-clipping.c
+++ b/src/vertex-clipping.c
@@ -206,6 +206,9 @@ clip_polygon_left(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_left_edge(ctx, src-x[i], src-y[i]);
@@ -222,6 +225,9 @@ clip_polygon_right(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_right_edge(ctx, src-x[i], src-y[i]);
@@ -238,6 +244,9 @@ clip_polygon_top(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_top_edge(ctx, src-x[i], src-y[i]);
@@ -254,6 +263,9 @@ clip_polygon_bottom(struct clip_context *ctx, const struct
polygon8 *src,
enum path_transition trans;
int i;
+ if (src-n 2)
+ return 0;
+
clip_context_prepare(ctx, src, dst_x, dst_y);
for (i = 0; i src-n; i++) {
trans = path_transition_bottom_edge(ctx, src-x[i], src-y[i]);
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 1/2] Remove duplicated code from cliptest.c
Signed-off-by: Ondřej Majerech oxyd.o...@gmail.com
---
Makefile.am| 2 +-
clients/cliptest.c | 293 +
2 files changed, 4 insertions(+), 291 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 191dcc9..8a27d44 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -476,7 +476,7 @@ weston_image_SOURCES = clients/image.c
weston_image_LDADD = libtoytoolkit.la
weston_image_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
-weston_cliptest_SOURCES = clients/cliptest.c
+weston_cliptest_SOURCES = clients/cliptest.c src/vertex-clipping.c
weston_cliptest_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
weston_cliptest_LDADD = libtoytoolkit.la
diff --git a/clients/cliptest.c b/clients/cliptest.c
index 907c5d4..af7bff1 100644
--- a/clients/cliptest.c
+++ b/clients/cliptest.c
@@ -49,6 +49,7 @@
#include linux/input.h
#include wayland-client.h
+#include src/vertex-clipping.h
#include window.h
typedef float GLfloat;
@@ -81,269 +82,6 @@ weston_surface_to_global_float(struct weston_surface
*surface,
*y = -g-s * sx + g-c * sy;
}
-/* -- copied begins ---*/
-
-struct polygon8 {
- GLfloat x[8];
- GLfloat y[8];
- int n;
-};
-
-struct clip_context {
- struct {
- GLfloat x;
- GLfloat y;
- } prev;
-
- struct {
- GLfloat x1, y1;
- GLfloat x2, y2;
- } clip;
-
- struct {
- GLfloat *x;
- GLfloat *y;
- } vertices;
-};
-
-static GLfloat
-float_difference(GLfloat a, GLfloat b)
-{
- /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
- static const GLfloat max_diff = 4.0f * FLT_MIN;
- static const GLfloat max_rel_diff = 4.0e-5;
- GLfloat diff = a - b;
- GLfloat adiff = fabsf(diff);
-
- if (adiff = max_diff)
- return 0.0f;
-
- a = fabsf(a);
- b = fabsf(b);
- if (adiff = (a b ? a : b) * max_rel_diff)
- return 0.0f;
-
- return diff;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
- * Compute the y coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat x_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1x, p2x);
-
- /* Practically vertical line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2y;
-
- a = (x_arg - p2x) / diff;
- return p2y + (p1y - p2y) * a;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line y = y_arg.
- * Compute the x coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_x(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat y_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1y, p2y);
-
- /* Practically horizontal line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2x;
-
- a = (y_arg - p2y) / diff;
- return p2x + (p1x - p2x) * a;
-}
-
-enum path_transition {
- PATH_TRANSITION_OUT_TO_OUT = 0,
- PATH_TRANSITION_OUT_TO_IN = 1,
- PATH_TRANSITION_IN_TO_OUT = 2,
- PATH_TRANSITION_IN_TO_IN = 3,
-};
-
-static void
-clip_append_vertex(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- *ctx-vertices.x++ = x;
- *ctx-vertices.y++ = y;
-}
-
-static enum path_transition
-path_transition_left_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.x = ctx-clip.x1) 1) | (x = ctx-clip.x1);
-}
-
-static enum path_transition
-path_transition_right_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.x ctx-clip.x2) 1) | (x ctx-clip.x2);
-}
-
-static enum path_transition
-path_transition_top_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.y = ctx-clip.y1) 1) | (y = ctx-clip.y1);
-}
-
-static enum path_transition
-path_transition_bottom_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.y ctx-clip.y2) 1) | (y ctx-clip.y2);
-}
-
-static void
-clip_polygon_leftright(struct clip_context *ctx,
- enum path_transition transition,
- GLfloat x, GLfloat y, GLfloat clip_x)
-{
- GLfloat yi;
-
- switch (transition) {
- case PATH_TRANSITION_IN_TO_IN:
-
Re: [PATCH weston 2/2] xwm: check whether the picked seat can be NULL
On Tue, 2014-08-19 at 16:53 +0300, Pekka Paalanen wrote: I was not able to reproduce the crash without the patch, and using gnome-terminal, either. Actually I'm also curious about how is the problem triggered, and I reproduced it on my machine just now. And I'm even more astonished to see this [1], though I can't reproduce it myself. It said that the picked seat can be NULL even in weston_wm_handle_button! I guess somewhere might be wrong in X (just a wild guess). Cheers, Boyan Ding [1] https://bugs.archlinux.org/task/41456 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: allow weird multitouch device without slots
2014-08-19 10:02 GMT+03:00 Peter Hutterer peter.hutte...@who-t.net: On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote: HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical Desktop=C2=AE 2.20 (connected to USB and identified as vendor 0x45e, pr= oduct 0xe3, version 0x111) is reported as supporting EV_ABS event with ABS_MT_SLOT code, but nevertheless libevdev_get_num_slots returns -1. yeah, that's intentional. libevdev detects those devices (through guesswork, but still...) and returns -1 as slot number. Furthermore, all connected devices (mouse and keyboard) don't produce a= ny EV_ABS events for that HID Mouse device in tests with evtest. Before this fix mouse didn't work in Weston (but worked in X.Org). As partially explained by LKML message [1] (Message-Id [2]): The root of the problem comes from hid-input, which maps unknown ax= is to ABS_MISC. However, when an event code is already in use, hid-inp= ut uses the one after, leading to uses of ABS_MISC + N, where N is the number of unknown axis. We are encountering a problem with the multitouch protocol here because if a device has more than 7 unknown axis (which is the case for the PS3 Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT and beyond. [1] https://lkml.org/lkml/2013/11/20/515 [2] 1384983141-31019-1-git-send-email-benjamin.tissoi...@redhat.com [...] so, as I said above the libevdev behaviour is intentional and our indicator that this isn't a MT device after all. We should integrate that knowledge better so that we don't label a device as touch device when it isn't, and so that we process events from those axes as normal ABS events instead of MT events. Unfortunately, my device (that Wireless Optical Desktop) doesn't produce any events with the questionable codes, so if I would try to change libinput behavior for these events to produce visible reaction, I'll not be able to test changes for sanity. I understand that my patch isn't general enough. It fixes my problem. though, making mouse working in Weston. Current libinput code isn't forgiving enough in handling of similar devices, so it cripples experience. I'm not complaining, it's v0.5, so missing functionality is acceptable, but it's frustrating. I will file a bug report in hope that someone will propose more general fix= . As a sidenote, cited LKML message says that the axis currently mapped on ABS_MT_SLOT is a special case in the kernel, and it is not updated, so I think processing axes as normal ABS events will not work for the axis reported as ABS_MT_SLOT. [Peter, sorry for spamming with this message in personal mail, it was my unintentional mistake in using Gmail UI.] ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: The road to Wayland/Weston 1.6 and 1.5.1
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Monday, August 18, 2014 4:36 AM To: wayland-devel@lists.freedesktop.org; krh@ Cc: Eoff, Ullysses A; Peter Hutterer; Jasper St. Pierre Subject: The road to Wayland/Weston 1.6 and 1.5.1 Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? Just wanted you to know I'm still following the project, albeit quite silently these days due to other tasks ;). Nonetheless, my test team is ready to ramp up our usual manual testing for this 1.6 release cycle. Our in-house automated builds and tests have still been running and continue to run without issue. I want to make sure we stay synced up during each phase of this release cycle. As you know, it takes us about 3-4 days to complete a manual test run... this includes execution, reflection, and reporting. As long as you plan to continue the usual 1 week phases for each alpha (1.5.91), beta 1 (1.5.92) and beta 2 (1.5.93) then we should be able to keep up. We don't have plans to add any new test cases to our manual test set this time. So our testing will only be regression testing, essentially. Also, our testing only covers the DRM (w/libinput) and X11 backends using the Desktop shell (w/cairo-glesv2) on specific Intel-based hardware. If there are new features and/or other recipes (hardware, backends, etc.) then I trust others will cover those. Cheers :), U. Artie Intel Open Source Technology Center I know the review process has been lagging behind badly, and we probably won't see e.g. IVI-shell merged for 1.6, but I try to do what I can. What major features have been forgotten on the mailing list unmerged, that you would like to see included in 1.6? I can't promise anything, and I know at least none of my new features (Presentation extension, new repaint scheduling algorithm, repaint timeline logging, DRM universal planes nuclear pageflip support, linux_dmabuf protocol sketch, and some smaller things) brewing in my personal 'next' branch will not make it. Obviously a stable first version of xdg_shell would be great to see in 1.6, but we shall see if we can beat it into shape in time. When I reviewed the XML spec not long ago, it was close but not ready in my opinion. When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland repository and it will be installed, but all build-time users of it must generate their own wrappers with wayland-scanner or equivalent. This means that libwayland-client will not contain any xdg_shell symbols or headers pre-generated. I asked Kristian and he was ok with this plan, and I have also talked a little on #wayland-devel, that maybe this would be a good idea. If this turns out a bad idea, we can always fix it later. Doing it the other way around would be near impossible. Should we make libinput the default for 1.6, so that in 1.7 we can remove the old input code, or is libinput API still too much in flux? Also, it was said that 1.5.1 should have come out in a few weeks and it has been 3 months now. I will try and check the patches already in 'master' of both Wayland and Weston and pick them to the 1.5 branches, but if you know of patches that should be in stable, especially ones without review or not in 'master', let me know and I try do something. My selection, especially for Wayland, will probably be very conservative, though, as my priority is 1.6. Thanks, pq [1] http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] client: add a public function to make a roundtrip on a custom queue
On Tue, Aug 19, 2014 at 3:58 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 16 Jul 2014 11:13:06 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-07-15 20:39 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Tuesday, July 15, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-07-14 22:31 GMT+03:00 Jason Ekstrand ja...@jlekstrand.net:
Guilio,
Would it be better to name it wl_event_queue_roundtrip and just
have it
take
the wl_event_queue? I guess it is sort-of a wl_display operation,
but
you
could argue it either way. Thoughts?
You have a point here, it makes more sense.
TBH I'd rather steer clear of that nomenclature, since the 'queue' in
an
immediate request context implies delayed dispatch, rather than on a
queue.
I didn't realize you could read it as queue a roundtrip on a
wl_event. I think that the meaning is quite obvious once you know
that there is a wl_event_queue type in Wayland.
Hi,
hm, that's a tricky one. Yes, the name wl_event_queue_roundtrip() is
confusing when out of context, but as the argument is a wl_event_queue,
that name is the logical and unfortunate result.
Another problem with wl_display_roundtrip_queue() is that it gets both
wl_display and wl_event_queue as arguments. Therefore the function
would need to check that the wl_event_queue indeed belongs to the given
wl_display. It's just a thing one can get wrong, and it has no benefits
that I see.
wl_display_roundtrip_queue() taking only wl_event_queue as an argument
would be strange, because the name implies a wl_display method.
(Up until this point, I would have agreed with Giulio and Jason...)
But, now I see, that we already have:
int wl_display_dispatch_queue(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_dispatch_queue_pending(struct wl_display *display,
struct wl_event_queue *queue);
int wl_display_prepare_read_queue(struct wl_display *display,
struct wl_event_queue *queue);
So there is precendent, that redundant arguments are ok, and
wl_display_roundtrip_queue() would indeed follow the existing scheme.
Btw. I do not see anywhere, where the libwayland-client code would be
checking that the wl_display and the wl_event_queue would actually be
related. Would be a good thing to add more checks to the public API
functions for that.
I think I would go with wl_display_roundtrip_queue() here. Would you
agree?
Yeah, you've convinced me. I don't like the name (and, by extension, don't
like the others) but it goes better with the current API. Let's go with
that.
--Jason
Thanks,
pq
On Mon, Jul 14, 2014 at 7:15 AM, Giulio Camuffo
giuliocamu...@gmail.com
wrote:
wl_display_roundtrip() works on the default queue. Add a parallel
wl_display_roundtrip_queue().
---
v3: fixed dispatch call in place of dispatch_queue
documented the queue parameter
src/wayland-client.c | 24 +---
src/wayland-client.h | 2 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index e8aab7e..d2c1b5c 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -834,15 +834,16 @@ static const struct wl_callback_listener
sync_listener = {
/** Block until all pending request are processed by the server
*
* \param display The display context object
+ * \param queue The queue on which to run the roundtrip
* \return The number of dispatched events on success or -1 on
failure
*
* Blocks until the server process all currently issued requests
and
- * sends out pending events on all event queues.
+ * sends out pending events on the event queue.
*
* \memberof wl_display
*/
WL_EXPORT int
-wl_display_roundtrip(struct wl_display *display)
+wl_display_roundtrip_queue(struct wl_display *display, struct
wl_event_queue *queue)
{
struct wl_callback *callback;
int done, ret = 0;
@@ -851,9 +852,10 @@ wl_display_roundtrip(struct wl_display
*display)
callback = wl_display_sync(display);
if (callback == NULL)
return -1;
+ wl_proxy_set_queue(callback, queue);
wl_callback_add_listener(callback, sync_listener, done);
while (!done ret = 0)
- ret = wl_display_dispatch(display);
+ ret = wl_display_dispatch_queue(display, queue);
if (ret == -1 !done)
wl_callback_destroy(callback);
@@ -861,6 +863,22 @@ wl_display_roundtrip(struct wl_display
*display)
return ret;
}
+/** Block until all pending request are processed by the server
+ *
+ * \param display The display
Re: [PATCH weston] configure.ac: use libinput by default
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Tue, Aug 19, 2014 at 3:13 AM, Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Libinput is stabilizing soon, so let's flip the default switch now. The old input code will still be carried as an option for a while. Cc: Peter Hutterer peter.hutte...@who-t.net Cc: Jonas Ådahl jad...@gmail.com Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 354db14..bc5c88a 100644 --- a/configure.ac +++ b/configure.ac @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then fi -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, - enable_libinput_backend=no) +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, + enable_libinput_backend=yes) AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend = xyes]) if test x$enable_libinput_backend = xyes; then AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input device backend]) -- 1.8.5.5 ___ 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 wayland v2] protocol: define the concept of wl_surface role
Pekka, I have one nitpick below. However, if we can't find a good solution, I'm ok with pushing as-is. Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Tue, Aug 19, 2014 at 1:41 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Tue, 19 Aug 2014 10:29:21 +0300 Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Define what a role is, and what restrictions there are. A change to existing behaviour is that a role cannot be changed at all once set. However, this is unlikely to cause problems, as there is no reason to re-use wl_surfaces in clients. v2: give more concrete examples of roles, define losing a role, Jasper rewrote the paragraph on how a role is set. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- protocol/wayland.xml | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2d57f69..d3fcaec 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -973,8 +973,30 @@ local coordinates of the pixel content, in case a buffer_transform or a buffer_scale is used. - Surfaces are also used for some special purposes, e.g. as - cursor images for pointers, drag icons, etc. + A surface without a role is fairly useless, a compositor does + not know where, when or how to present it. The role is the + purpose of a wl_surface. Examples of roles are a cursor for a + pointer (as set by wl_pointer.set_cursor), a drag icon + (wl_data_device.start_drag), a sub-surface + (wl_subcompositor.get_subsurface), and a window as defined by a + shell protocol (e.g. wl_shell.get_shell_surface). + + A surface can have only one role at a time. Initially a + wl_surface does not have a role. Once a wl_surface is given a + role, it can never be given a different role again, even if the + wl_surface loses the role in between. I don't really like the term looses its role. Once a surface is a cursor surface it is always a cursor surface, it just might not be the *current* currsor surface. How about: A surface can only have one role in its lifetime. Even if the surface stops being actively used in its role, it can never be used in any other role. For instance, once you call wl_pointer.set_cursor on a surface, the surface is now a cursor surface. Even if it stops being the active cursor, the wl_surface object retains the cursor role cannot be used in a different role. Thoughts? + + Surface roles are set by requests in other interfaces such as Bah... forgot to save one tiny change: Surface roles are given by ... ---^ Thanks, pq + wl_pointer.set_cursor. The request should explicitly mention + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. + + A wl_surface may lose its role as specified in the interface + that gave it the role or in the interface of the role object. + Losing a role means losing all the role-specific state. /description enum name=error ___ 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 weston] configure.ac: use libinput by default
On Tue, Aug 19, 2014 at 09:46:55AM -0700, Jason Ekstrand wrote: Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com Acked-by: Jonas Ådahl jad...@gmail.com On Tue, Aug 19, 2014 at 3:13 AM, Pekka Paalanen ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk Libinput is stabilizing soon, so let's flip the default switch now. The old input code will still be carried as an option for a while. Cc: Peter Hutterer peter.hutte...@who-t.net Cc: Jonas Ådahl jad...@gmail.com Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 354db14..bc5c88a 100644 --- a/configure.ac +++ b/configure.ac @@ -155,8 +155,8 @@ if test x$enable_drm_compositor = xyes; then fi -AC_ARG_ENABLE(libinput-backend, [ --enable-libinput-backend],, - enable_libinput_backend=no) +AC_ARG_ENABLE(libinput-backend, [ --disable-libinput-backend],, + enable_libinput_backend=yes) AM_CONDITIONAL([ENABLE_LIBINPUT_BACKEND], [test x$enable_libinput_backend = xyes]) if test x$enable_libinput_backend = xyes; then AC_DEFINE([BUILD_LIBINPUT_BACKEND], [1], [Build the libinput input device backend]) -- 1.8.5.5 ___ 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
[ANNOUNCE] libxkbcommon 0.4.3
A new release of libxkbcommon, containing mostly bug-fixes. libxkbcommon 0.4.3 - 2014-08-19 == - Fixed a bug which caused xkb_x11_keymap_new_from_device() to misrepresent modifiers for some keymaps. https://github.com/xkbcommon/libxkbcommon/issues/9 - Fixed a bug which caused xkb_x11_keymap_new_from_device() to ignore XKB PrivateAction's. - Modifiers are now always fully resolved after xkb_state_update_mask(). Previously the given state components were used as-is, without considering virtual modifier mappings. Note: this only affects non-standard uses of xkb_state_update_mask(). - Added a test for xkbcommon-x11, x11comp. The test uses the system's Xvfb server and xkbcomp. If they do not exist or fail, the test is skipped. - Fixed memory leaks after parse errors in the XKB yacc parser. The fix required changes which are currently incompatible with byacc. https://github.com/xkbcommon/libxkbcommon/issues/8 Tarballs: git tag: xkbcommon-0.4.3 http://xkbcommon.org/download/libxkbcommon-0.4.3.tar.xz MD5: 26c57ff21438ed45de2a4ca609177db9 libxkbcommon-0.4.3.tar.xz SHA1: 2251adc7425c816ec7af4f1c3776a619a53293b6 libxkbcommon-0.4.3.tar.xz Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] compositor: add a way to change the keyboard leds
This adds a function weston_keyboard_set_leds() which can be used
to change the state of the num lock and the caps lock leds.
Only the evdev backend supports this, since it doesn't make sense
for embedded sessions.
---
src/compositor.h | 3 +++
src/input.c | 43 +++
2 files changed, 46 insertions(+)
diff --git a/src/compositor.h b/src/compositor.h
index c0fc0a6..0c5c98a 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -393,6 +393,9 @@ weston_keyboard_start_grab(struct weston_keyboard *device,
struct weston_keyboard_grab *grab);
void
weston_keyboard_end_grab(struct weston_keyboard *keyboard);
+int
+weston_keyboard_set_leds(struct weston_keyboard *keyboard,
+enum weston_led leds, enum weston_led active);
struct weston_touch *
weston_touch_create(void);
diff --git a/src/input.c b/src/input.c
index 1ab55ce..d0637b8 100644
--- a/src/input.c
+++ b/src/input.c
@@ -1064,6 +1064,49 @@ notify_axis(struct weston_seat *seat, uint32_t time,
uint32_t axis,
value);
}
+WL_EXPORT int
+weston_keyboard_set_leds(struct weston_keyboard *keyboard,
+enum weston_led leds, enum weston_led active)
+{
+ /* We don't want the leds to go out of sync with the actual state
+* so if the backend has no way to change the leds don't try to
+* change the state */
+ if (!keyboard-seat-led_update)
+ return -1;
+
+ uint32_t mods_depressed, mods_latched, mods_locked, group;
+ uint32_t serial;
+ int num, caps;
+ mods_depressed = xkb_state_serialize_mods(keyboard-xkb_state.state,
+ XKB_STATE_DEPRESSED);
+ mods_latched = xkb_state_serialize_mods(keyboard-xkb_state.state,
+ XKB_STATE_LATCHED);
+ mods_locked = xkb_state_serialize_mods(keyboard-xkb_state.state,
+ XKB_STATE_LOCKED);
+ group = xkb_state_serialize_group(keyboard-xkb_state.state,
+ XKB_STATE_EFFECTIVE);
+
+ num = (1 keyboard-xkb_info-mod2_mod);
+ caps = (1 keyboard-xkb_info-caps_mod);
+ if (leds LED_NUM_LOCK)
+ mods_locked = (active LED_NUM_LOCK) ? mods_locked | num
+ : mods_locked ~num;
+ if (leds LED_CAPS_LOCK)
+ mods_locked = (active LED_CAPS_LOCK) ? mods_locked | caps
+ : mods_locked ~caps;
+ if (leds LED_SCROLL_LOCK)
+ weston_log(Changing the LED_SCROLL_LOCK value is not
supported.);
+
+ xkb_state_update_mask(keyboard-xkb_state.state, mods_depressed,
+ mods_latched, mods_locked, 0, 0, group);
+
+ serial = wl_display_next_serial(
+ keyboard-seat-compositor-wl_display);
+ notify_modifiers(keyboard-seat, serial);
+
+ return 0;
+}
+
#ifdef ENABLE_XKBCOMMON
WL_EXPORT void
notify_modifiers(struct weston_seat *seat, uint32_t serial)
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] evdev: turn off all the leds at startup
the internal state in xkbcommon is off for all the three leds, so
make them be in sync.
---
src/evdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/evdev.c b/src/evdev.c
index 888dfbd..a46ed87 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -581,6 +581,7 @@ evdev_configure_device(struct evdev_device *device)
device-seat_caps |= EVDEV_SEAT_KEYBOARD;
weston_log(input device %s, %s is a keyboard\n,
device-devname, device-devnode);
+ evdev_led_update(device, 0);
}
if (has_touch !has_button) {
weston_seat_init_touch(device-seat);
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] weston.ini.man: Add libinput section
Signed-off-by: Jonas Ådahl jad...@gmail.com --- man/weston.ini.man | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man/weston.ini.man b/man/weston.ini.man index fbcec81..4be752b 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -70,6 +70,7 @@ The section headers are: .RS 4 .nf .BR coreThe core modules +.BR libinputInput device configuration .BR shell Desktop customization .BR launcherAdd launcher to the panel .BR screensaver Screensaver selection @@ -144,6 +145,19 @@ By default, xrgb is used. .RS .PP +.SH LIBINPUT SECTION +The +.B libinput +section is used to configure input devices when using the libinput input device +backend. +.PP +Available configuration are: +.TP 7 +.BI enable_tap= true +enables tap to click on touchpad devices +.RS +.PP + .SH SHELL SECTION The .B shell -- 1.8.5.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2] protocol: define the concept of wl_surface role
On 08/19/2014 12:29 AM, Pekka Paalanen wrote: + Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a + client wants to destroy a wl_surface, they must destroy this 'role + object' before the wl_surface. Destroying the last protocol object for the role does not remove the role, correct? The client can recreate a new protocol object for that role and it still works? + Losing a role means losing all the role-specific state. I'm not sure what you are saying here. I think maybe you are talking about a surface that was used for drag drop when the drag drop ends? I thought in that case the surface must be destroyed: ie once a surface loses a role it cannot be assigned any role, including the same one. But in that case the state is irrelevant. Are you allowed to reuse the drag drop surface for another drag drop? If the creation request also sets some state it is obvious that portion of the state is not preserved. But it seems a lot easier on both clients and compositors if other state is allowed to be preserved. In any case I find this sentence really confusing. Also it might help if there was a concrete example of a surface losing a role. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/2] Replace deprecated xkbcommon symbols with current names
These symbols (xkb_map_* and others) were replaced in xkbcommon with more
consistent names. See the header xkbcommon/xkbcommon-compat.h for how
the old names map to the new.
The new names have been available since the first stable xkbcommon
release (0.2.0).
Signed-off-by: Ran Benita ran...@gmail.com
---
clients/weston-simple-im.c | 22
clients/window.c | 24 -
src/compositor-wayland.c | 10 +++
src/compositor-x11.c | 4 +--
src/input.c| 66 --
src/screen-share.c | 10 +++
6 files changed, 70 insertions(+), 66 deletions(-)
diff --git a/clients/weston-simple-im.c b/clients/weston-simple-im.c
index ded6a04..787782f 100644
--- a/clients/weston-simple-im.c
+++ b/clients/weston-simple-im.c
@@ -187,10 +187,10 @@ input_method_keyboard_keymap(void *data,
}
keyboard-keymap =
- xkb_map_new_from_string(keyboard-xkb_context,
- map_str,
- XKB_KEYMAP_FORMAT_TEXT_V1,
- 0);
+ xkb_keymap_new_from_string(keyboard-xkb_context,
+ map_str,
+ XKB_KEYMAP_FORMAT_TEXT_V1,
+ 0);
munmap(map_str, size);
close(fd);
@@ -203,16 +203,16 @@ input_method_keyboard_keymap(void *data,
keyboard-state = xkb_state_new(keyboard-keymap);
if (!keyboard-state) {
fprintf(stderr, failed to create XKB state\n);
- xkb_map_unref(keyboard-keymap);
+ xkb_keymap_unref(keyboard-keymap);
return;
}
keyboard-control_mask =
- 1 xkb_map_mod_get_index(keyboard-keymap, Control);
+ 1 xkb_keymap_mod_get_index(keyboard-keymap, Control);
keyboard-alt_mask =
- 1 xkb_map_mod_get_index(keyboard-keymap, Mod1);
+ 1 xkb_keymap_mod_get_index(keyboard-keymap, Mod1);
keyboard-shift_mask =
- 1 xkb_map_mod_get_index(keyboard-keymap, Shift);
+ 1 xkb_keymap_mod_get_index(keyboard-keymap, Shift);
}
static void
@@ -234,7 +234,7 @@ input_method_keyboard_key(void *data,
return;
code = key + 8;
- num_syms = xkb_key_get_syms(keyboard-state, code, syms);
+ num_syms = xkb_state_key_get_syms(keyboard-state, code, syms);
sym = XKB_KEY_NoSymbol;
if (num_syms == 1)
@@ -261,8 +261,8 @@ input_method_keyboard_modifiers(void *data,
xkb_state_update_mask(keyboard-state, mods_depressed,
mods_latched, mods_locked, 0, 0, group);
mask = xkb_state_serialize_mods(keyboard-state,
- XKB_STATE_DEPRESSED |
- XKB_STATE_LATCHED);
+ XKB_STATE_MODS_DEPRESSED |
+ XKB_STATE_MODS_LATCHED);
keyboard-modifiers = 0;
if (mask keyboard-control_mask)
diff --git a/clients/window.c b/clients/window.c
index a8bc260..90f45d3 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2749,10 +2749,10 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
return;
}
- keymap = xkb_map_new_from_string(input-display-xkb_context,
-map_str,
-XKB_KEYMAP_FORMAT_TEXT_V1,
-0);
+ keymap = xkb_keymap_new_from_string(input-display-xkb_context,
+ map_str,
+ XKB_KEYMAP_FORMAT_TEXT_V1,
+ 0);
munmap(map_str, size);
close(fd);
@@ -2764,7 +2764,7 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
state = xkb_state_new(keymap);
if (!state) {
fprintf(stderr, failed to create XKB state\n);
- xkb_map_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
}
@@ -2774,11 +2774,11 @@ keyboard_handle_keymap(void *data, struct wl_keyboard
*keyboard,
input-xkb.state = state;
input-xkb.control_mask =
- 1 xkb_map_mod_get_index(input-xkb.keymap, Control);
+ 1 xkb_keymap_mod_get_index(input-xkb.keymap, Control);
input-xkb.alt_mask =
- 1 xkb_map_mod_get_index(input-xkb.keymap, Mod1);
+ 1 xkb_keymap_mod_get_index(input-xkb.keymap, Mod1);
input-xkb.shift_mask =
- 1 xkb_map_mod_get_index(input-xkb.keymap, Shift);
+ 1 xkb_keymap_mod_get_index(input-xkb.keymap, Shift);
}
static void
@@ -2834,7 +2834,7 @@ keyboard_handle_key(void *data,
[PATCH weston 2/2] Don't protect xkb_*_unref from NULL
Since xkbcommon-0.3.0, which is required by weston, a NULL argument
doesn't do anything.
Signed-off-by: Ran Benita ran...@gmail.com
---
src/compositor-wayland.c | 3 +--
src/compositor-x11.c | 3 +--
src/input.c | 9 +++--
src/screen-share.c | 3 +--
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 57e850f..5f73c78 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1464,8 +1464,7 @@ input_handle_keymap(void *data, struct wl_keyboard
*keyboard, uint32_t format,
else
weston_seat_init_keyboard(input-base, keymap);
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 984d799..3494e34 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -322,8 +322,7 @@ x11_input_create(struct x11_compositor *c, int no_input)
keymap = x11_compositor_get_keymap(c);
if (weston_seat_init_keyboard(c-core_seat, keymap) 0)
return -1;
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
x11_compositor_setup_xkb(c);
diff --git a/src/input.c b/src/input.c
index 2130789..975cd77 100644
--- a/src/input.c
+++ b/src/input.c
@@ -544,12 +544,10 @@ weston_keyboard_destroy(struct weston_keyboard *keyboard)
#ifdef ENABLE_XKBCOMMON
if (keyboard-seat-compositor-use_xkbcommon) {
- if (keyboard-xkb_state.state != NULL)
- xkb_state_unref(keyboard-xkb_state.state);
+ xkb_state_unref(keyboard-xkb_state.state);
if (keyboard-xkb_info)
weston_xkb_info_destroy(keyboard-xkb_info);
- if (keyboard-pending_keymap)
- xkb_keymap_unref(keyboard-pending_keymap);
+ xkb_keymap_unref(keyboard-pending_keymap);
}
#endif
@@ -1869,8 +1867,7 @@ weston_xkb_info_destroy(struct weston_xkb_info *xkb_info)
if (--xkb_info-ref_count 0)
return;
- if (xkb_info-keymap)
- xkb_keymap_unref(xkb_info-keymap);
+ xkb_keymap_unref(xkb_info-keymap);
if (xkb_info-keymap_area)
munmap(xkb_info-keymap_area, xkb_info-keymap_size);
diff --git a/src/screen-share.c b/src/screen-share.c
index 9e81ef9..524a0ca 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -214,8 +214,7 @@ ss_seat_handle_keymap(void *data, struct wl_keyboard
*keyboard,
else
weston_seat_init_keyboard(seat-base, keymap);
- if (keymap)
- xkb_keymap_unref(keymap);
+ xkb_keymap_unref(keymap);
return;
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2 1/3] parse_options: fail on more malformed options
Fail on trailing text after numbers, such as --width=100mm
Fail on any text after booleans, such as --flag=false
Also fixed reading of memory after the null terminator of a long
option with no = sign in it.
---
shared/option-parser.c | 89 +---
1 file changed, 61 insertions(+), 28 deletions(-)
diff --git a/shared/option-parser.c b/shared/option-parser.c
index c00349a..b8e7394 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -30,53 +30,86 @@
#include config-parser.h
-static void
+static int
handle_option(const struct weston_option *option, char *value)
{
+ char* p;
+
switch (option-type) {
case WESTON_OPTION_INTEGER:
- * (int32_t *) option-data = strtol(value, NULL, 0);
- return;
+ * (int32_t *) option-data = strtol(value, p, 0);
+ return *value !*p;
case WESTON_OPTION_UNSIGNED_INTEGER:
- * (uint32_t *) option-data = strtoul(value, NULL, 0);
- return;
+ * (uint32_t *) option-data = strtoul(value, p, 0);
+ return *value !*p;
case WESTON_OPTION_STRING:
* (char **) option-data = strdup(value);
- return;
- case WESTON_OPTION_BOOLEAN:
- * (int32_t *) option-data = 1;
- return;
+ return 1;
default:
assert(0);
}
}
+static int
+long_option(const struct weston_option *options, int count, char* arg)
+{
+ int k, len;
+
+ for (k = 0; k count; k++) {
+ if (!options[k].name)
+ continue;
+ len = strlen(options[k].name);
+ if (strncmp(options[k].name, arg + 2, len) != 0)
+ continue;
+ if (options[k].type == WESTON_OPTION_BOOLEAN) {
+ if (!arg[len + 2]) {
+ * (int32_t *) options[k].data = 1;
+ return 1;
+ }
+ } else if (arg[len+2] == '=') {
+ return handle_option(options + k, arg + len + 3);
+ }
+ }
+ return 0;
+}
+
+static int
+short_option(const struct weston_option *options, int count, char* arg)
+{
+ int k;
+
+ if (!arg[1])
+ return 0;
+ for (k = 0; k count; k++) {
+ if (options[k].short_name != arg[1])
+ continue;
+ if (options[k].type == WESTON_OPTION_BOOLEAN) {
+ if (!arg[2]) {
+ * (int32_t *) options[k].data = 1;
+ return 1;
+ }
+ } else {
+ return handle_option(options + k, arg + 2);
+ }
+ }
+ return 0;
+}
+
int
parse_options(const struct weston_option *options,
int count, int *argc, char *argv[])
{
- int i, j, k, len = 0;
+ int i, j;
for (i = 1, j = 1; i *argc; i++) {
- for (k = 0; k count; k++) {
- if (options[k].name)
- len = strlen(options[k].name);
- if (options[k].name
- argv[i][0] == '-'
- argv[i][1] == '-'
- strncmp(options[k].name, argv[i][2], len) == 0
- (argv[i][len + 2] == '=' || argv[i][len + 2] ==
'\0')) {
- handle_option(options[k], argv[i][len + 3]);
- break;
- } else if (options[k].short_name
- argv[i][0] == '-'
- options[k].short_name == argv[i][1]) {
- handle_option(options[k], argv[i][2]);
- break;
- }
+ if (argv[i][0] == '-') {
+ if (argv[i][1] == '-') {
+ if (long_option(options, count, argv[i]))
+ continue;
+ } else if (short_option(options, count, argv[i]))
+ continue;
}
- if (k == count)
- argv[j++] = argv[i];
+ argv[j++] = argv[i];
}
argv[j] = NULL;
*argc = j;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH V2 3/3] image: don't print redundant error
This error is printed by load_image() now
---
clients/image.c |1 -
1 file changed, 1 deletion(-)
diff --git a/clients/image.c b/clients/image.c
index 573117c..aee8112 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -373,7 +373,6 @@ image_create(struct display *display, const char *filename,
image-image = load_cairo_surface(filename);
if (!image-image) {
- fprintf(stderr, could not find the image %s!\n, b);
free(image-filename);
free(image);
return NULL;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput] test: avoid erroneous devices to be passed into the test suites
The litest features overlap with the litest device specifiers, so it's easy to
pass in LITEST_MOUSE where LITEST_POINTER should be passed in, and vice versa.
Lacking proper type checking the best we can do here is simply move the
devices into the negative range and check for that.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/litest.c | 5 +
test/litest.h | 18 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index 00db464..0341e9a 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -157,6 +157,9 @@ litest_add_tcase(struct suite *suite, void *func,
{
struct litest_test_device **dev = devices;
+ assert(required = LITEST_DISABLE_DEVICE);
+ assert(excluded = LITEST_DISABLE_DEVICE);
+
if (required == LITEST_DISABLE_DEVICE
excluded == LITEST_DISABLE_DEVICE) {
litest_add_tcase_no_device(suite, func);
@@ -221,6 +224,8 @@ litest_add_for_device(const char *name,
struct suite *s;
struct litest_test_device **dev = devices;
+ assert(type LITEST_NO_DEVICE);
+
s = get_suite(name);
while (*dev) {
if ((*dev)-type == type) {
diff --git a/test/litest.h b/test/litest.h
index 2dcb7b2..aac71e4 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -35,15 +35,15 @@
enum litest_device_type {
LITEST_NO_DEVICE = -1,
- LITEST_SYNAPTICS_CLICKPAD,
- LITEST_SYNAPTICS_TOUCHPAD,
- LITEST_SYNAPTICS_TOPBUTTONPAD,
- LITEST_BCM5974,
- LITEST_KEYBOARD,
- LITEST_TRACKPOINT,
- LITEST_MOUSE,
- LITEST_WACOM_TOUCH,
- LITEST_ALPS_SEMI_MT,
+ LITEST_SYNAPTICS_CLICKPAD = -2,
+ LITEST_SYNAPTICS_TOUCHPAD = -3,
+ LITEST_SYNAPTICS_TOPBUTTONPAD = -4,
+ LITEST_BCM5974 = -5,
+ LITEST_KEYBOARD = -6,
+ LITEST_TRACKPOINT = -7,
+ LITEST_MOUSE = -8,
+ LITEST_WACOM_TOUCH = -9,
+ LITEST_ALPS_SEMI_MT = -10,
};
enum litest_device_feature {
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/8] evdev: factor out closing a device into evdev_suspend()
No functional changes, just prep work for an upcoming patch
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c | 13 +++--
src/evdev.h | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index b9f635d..8b154a3 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1058,8 +1058,8 @@ release_pressed_keys(struct evdev_device *device)
}
}
-void
-evdev_device_remove(struct evdev_device *device)
+int
+evdev_device_suspend(struct evdev_device *device)
{
if (device-source)
libinput_remove_source(device-base.seat-libinput,
@@ -1071,6 +1071,15 @@ evdev_device_remove(struct evdev_device *device)
mtdev_close_delete(device-mtdev);
close_restricted(device-base.seat-libinput, device-fd);
device-fd = -1;
+
+ return 0;
+}
+
+void
+evdev_device_remove(struct evdev_device *device)
+{
+ evdev_device_suspend(device);
+
list_remove(device-base.link);
notify_removed_device(device-base);
diff --git a/src/evdev.h b/src/evdev.h
index f1ccdc2..05125b7 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -179,6 +179,8 @@ double
evdev_device_transform_y(struct evdev_device *device,
double y,
uint32_t height);
+int
+evdev_device_suspend(struct evdev_device *device);
void
evdev_keyboard_notify_key(struct evdev_device *device,
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 8/8] test: test for release events on device suspend
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/device.c | 149 ++
1 file changed, 149 insertions(+)
diff --git a/test/device.c b/test/device.c
index 25e119e..2367fd6 100644
--- a/test/device.c
+++ b/test/device.c
@@ -30,6 +30,7 @@
#include unistd.h
#include litest.h
+#include libinput-util.h
static int open_restricted(const char *path, int flags, void *data)
{
@@ -238,6 +239,151 @@ START_TEST(device_resume_invalid_device_removed)
}
END_TEST
+START_TEST(device_suspend_release_buttons)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_pointer *ptrevent;
+
+ device = dev-libinput_device;
+
+ litest_button_click(dev, BTN_LEFT, true);
+ litest_drain_events(li);
+ litest_assert_empty_queue(li);
+
+ libinput_device_suspend(device);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+ ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrevent),
+LIBINPUT_BUTTON_STATE_RELEASED);
+
+ libinput_event_destroy(event);
+ litest_assert_empty_queue(li);
+
+ /* double-suspend for good measure, make sure we don't get
+* the button events again */
+ libinput_device_suspend(device);
+ libinput_dispatch(li);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_suspend_release_keys)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_keyboard *kbdevent;
+
+ device = dev-libinput_device;
+
+ litest_button_click(dev, KEY_A, true);
+ litest_drain_events(li);
+ litest_assert_empty_queue(li);
+
+ libinput_device_suspend(device);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_KEYBOARD_KEY);
+ kbdevent = libinput_event_get_keyboard_event(event);
+ ck_assert_int_eq(libinput_event_keyboard_get_key(kbdevent),
+KEY_A);
+ ck_assert_int_eq(libinput_event_keyboard_get_key_state(kbdevent),
+LIBINPUT_KEY_STATE_RELEASED);
+
+ libinput_event_destroy(event);
+ litest_assert_empty_queue(li);
+
+ /* double-suspend for good measure, make sure we don't get
+* the key events again */
+ libinput_device_suspend(device);
+ libinput_dispatch(li);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_suspend_release_tap)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+ struct libinput_event *event;
+ struct libinput_event_pointer *ptrevent;
+
+ device = dev-libinput_device;
+
+ libinput_device_config_tap_set_enabled(device,
+ LIBINPUT_CONFIG_TAP_ENABLED);
+
+ litest_drain_events(li);
+
+ litest_touch_down(dev, 0, 50, 50);
+ litest_touch_up(dev, 0);
+
+ libinput_dispatch(li);
+
+ libinput_device_suspend(device);
+ /* tap happened before suspending, so we still expect the event */
+
+ msleep(300); /* tap-n-drag timeout */
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+ ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrevent),
+LIBINPUT_BUTTON_STATE_PRESSED);
+
+ libinput_event_destroy(event);
+
+ while ((event = libinput_get_event(li)) == NULL)
+ libinput_dispatch(li);
+
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_BUTTON);
+ ptrevent = libinput_event_get_pointer_event(event);
+ ck_assert_int_eq(libinput_event_pointer_get_button(ptrevent),
+BTN_LEFT);
+
[PATCH libinput 5/8] test: add test for device suspend/resume
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/Makefile.am | 7 +-
test/device.c| 250 +++
2 files changed, 256 insertions(+), 1 deletion(-)
create mode 100644 test/device.c
diff --git a/test/Makefile.am b/test/Makefile.am
index 76d4e8c..4602f9f 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -34,7 +34,8 @@ run_tests = \
test-log \
test-touchpad \
test-misc \
- test-keyboard
+ test-keyboard \
+ test-device
build_tests = \
test-build-cxx \
test-build-linker \
@@ -78,6 +79,10 @@ test_keyboard_SOURCES = keyboard.c
test_keyboard_LDADD = $(TEST_LIBS)
test_keyboard_LDFLAGS = -no-install
+test_device_SOURCES = device.c
+test_device_LDADD = $(TEST_LIBS)
+test_device_LDFLAGS = -no-install
+
# build-test only
test_build_pedantic_c99_SOURCES = build-pedantic.c
test_build_pedantic_c99_CFLAGS = -std=c99 -pedantic -Werror
diff --git a/test/device.c b/test/device.c
new file mode 100644
index 000..25e119e
--- /dev/null
+++ b/test/device.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright © 2014 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission. The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose. It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include config.h
+
+#include check.h
+#include errno.h
+#include fcntl.h
+#include libinput.h
+#include libudev.h
+#include unistd.h
+
+#include litest.h
+
+static int open_restricted(const char *path, int flags, void *data)
+{
+ int fd;
+ fd = open(path, flags);
+ return fd 0 ? -errno : fd;
+}
+static void close_restricted(int fd, void *data)
+{
+ close(fd);
+}
+
+const struct libinput_interface simple_interface = {
+ .open_restricted = open_restricted,
+ .close_restricted = close_restricted,
+};
+
+
+START_TEST(device_suspend)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+
+ device = dev-libinput_device;
+
+ litest_drain_events(li);
+
+ /* no event from suspending */
+ libinput_device_suspend(device);
+ litest_assert_empty_queue(li);
+
+ /* no event from suspended device */
+ litest_event(dev, EV_REL, REL_X, 10);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ litest_assert_empty_queue(li);
+
+ /* no event from resuming */
+ libinput_device_resume(device);
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_double_suspend)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+
+ device = dev-libinput_device;
+
+ litest_drain_events(li);
+
+ libinput_device_suspend(device);
+ libinput_device_suspend(device);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_double_resume)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_device *device;
+
+ device = dev-libinput_device;
+
+ litest_drain_events(li);
+
+ libinput_device_suspend(device);
+ libinput_device_resume(device);
+ libinput_device_resume(device);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(device_resume_invalid_syspath_changed)
+{
+ struct libinput *li;
+ struct libinput_device *device;
+ struct libevdev *evdev;
+ struct libevdev_uinput *uinput;
+ int rc;
+ char *devnode;
+
+ evdev = libevdev_new();
+ ck_assert_notnull(evdev);
+
+ libevdev_set_name(evdev, litest device);
+ libevdev_enable_event_code(evdev, EV_KEY, BTN_LEFT, NULL);
+ libevdev_enable_event_code(evdev, EV_KEY, BTN_RIGHT, NULL);
+ libevdev_enable_event_code(evdev, EV_REL, REL_X, NULL);
+ libevdev_enable_event_code(evdev, EV_REL, REL_Y,
[PATCH libinput 6/8] evdev: drop the button count when releasing keys on remove
We only called this function before device removal, so failing to update the button state didn't matter. To make this function generic for the upcoming device suspend/resume, we need to keep track of the button/key count properly. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/evdev.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 74632c8..6bbea92 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1042,15 +1042,15 @@ release_pressed_keys(struct evdev_device *device) case EVDEV_KEY_TYPE_NONE: break; case EVDEV_KEY_TYPE_KEY: - keyboard_notify_key( - device-base, + evdev_keyboard_notify_key( + device, time, code, LIBINPUT_KEY_STATE_RELEASED); break; case EVDEV_KEY_TYPE_BUTTON: - pointer_notify_button( - device-base, + evdev_pointer_notify_button( + device, time, code, LIBINPUT_BUTTON_STATE_RELEASED); -- 1.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 7/8] evdev: ignore excessive releases of a button or key
When we're suspending a touchpad, several events triggered by timers may still
be waiting in the background. We still need to release all buttons/keys
immediately though so we get an uneven number of release events: one from
release_pressed_keys() and one when the timers expire and send the release
event through the normal channels.
Don't assert if we're already on a press-count of 0, simply ignore it and
discard the event.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
I'm not 100% sure on this one. It's the easy solution, but until we know the
general direction I didn't want to implement the full solution.
What's needed here are hooks for suspending/resuming in the dispatch structs
so that the touchpad code can cancel anything currently happening and reset
the state. For the normal fallback_dispatch the hooks can just release keys
and touches.
src/evdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 6bbea92..755e7a1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -74,8 +74,10 @@ update_key_down_count(struct evdev_device *device, int code,
int pressed)
if (pressed) {
key_count = ++device-key_count[code];
} else {
- assert(device-key_count[code] 0);
- key_count = --device-key_count[code];
+ if (device-key_count[code] 0)
+ key_count = --device-key_count[code];
+ else
+ return -1;
}
if (key_count 32) {
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/8] Add libinput_device_suspend() and libinput_device_resume()
Does what it says on the box, preventing events from the device without actually
dropping the device from the context.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
See my notes in the coverletter. For the T440 case I specifically did not
mention that _suspend() closes the file descriptors.
src/evdev.c| 23 +++
src/evdev.h| 3 +++
src/libinput.c | 16
src/libinput.h | 45 +
4 files changed, 87 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index d4a4a07..78d9985 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1082,6 +1082,29 @@ evdev_device_suspend(struct evdev_device *device)
return 0;
}
+int
+evdev_device_resume(struct evdev_device *device)
+{
+ struct libinput *libinput = device-base.seat-libinput;
+ int fd;
+
+ if (device-fd != -1)
+ return 0;
+
+ fd = open_restricted(libinput, device-devnode, O_RDWR | O_NONBLOCK);
+
+ if (fd 0)
+ return fd;
+
+ device-fd = fd;
+ device-source =
+ libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
+ if (!device-source)
+ return -ENOMEM;
+
+ return 0;
+}
+
void
evdev_device_remove(struct evdev_device *device)
{
diff --git a/src/evdev.h b/src/evdev.h
index 05125b7..b4749b6 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -182,6 +182,9 @@ evdev_device_transform_y(struct evdev_device *device,
int
evdev_device_suspend(struct evdev_device *device);
+int
+evdev_device_resume(struct evdev_device *device);
+
void
evdev_keyboard_notify_key(struct evdev_device *device,
uint32_t time,
diff --git a/src/libinput.c b/src/libinput.c
index 90b6a13..d18d9b8 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1142,6 +1142,22 @@ libinput_suspend(struct libinput *libinput)
libinput-interface_backend-suspend(libinput);
}
+LIBINPUT_EXPORT int
+libinput_device_suspend(struct libinput_device *device)
+{
+ struct evdev_device *dev = (struct evdev_device*)device;
+
+ return evdev_device_suspend(dev);
+}
+
+LIBINPUT_EXPORT int
+libinput_device_resume(struct libinput_device *device)
+{
+ struct evdev_device *dev = (struct evdev_device*)device;
+
+ return evdev_device_resume(dev);
+}
+
LIBINPUT_EXPORT void
libinput_device_set_user_data(struct libinput_device *device, void *user_data)
{
diff --git a/src/libinput.h b/src/libinput.h
index 9296a35..338a08f 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1226,6 +1226,51 @@ libinput_device_unref(struct libinput_device *device);
/**
* @ingroup device
*
+ * Suspend the device but do not remove the device from the context.
+ * Suspending a device stops the device from generating events until it is
+ * either resumed with libinput_device_resume() or removed from the context.
+ * Suspending a device does not generate a @ref
+ * LIBINPUT_EVENT_DEVICE_REMOVED event.
+ *
+ * Events already received and processed from this device are unaffected and
+ * will be passed to the caller on the next call to libinput_get_event().
+ * When the device is suspended, it may generate events to reset it into a
+ * neutral state (e.g. releasing currently pressed buttons).
+ *
+ * If the device is already suspended, this function does nothing.
+ *
+ * @param device A previously obtained device
+ * @return 0 on success or a negative errno on failure
+ *
+ * @see libinput_device_resume
+ */
+int
+libinput_device_suspend(struct libinput_device *device);
+
+/**
+ * @ingroup device
+ *
+ * Resume a previously suspended device. Events from this device will be
+ * processed in the next call of libinput_dispatch().
+ * Resuming a device does not generate a @ref LIBINPUT_EVENT_DEVICE_ADDED
+ * event.
+ *
+ * When the device is resumed, it may generate events to match the logical
+ * state with the current physical state of the device.
+ *
+ * If the device is not currently suspended, this function does nothing.
+ *
+ * @param device A previously suspended device
+ * @return 0 on success or a negative errno on failure
+ *
+ * @see libinput_device_suspend
+ */
+int
+libinput_device_resume(struct libinput_device *device);
+
+/**
+ * @ingroup device
+ *
* Set caller-specific data associated with this input device. libinput does
* not manage, look at, or modify this data. The caller must ensure the
* data is valid.
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/8] evdev: don't resume a removed device
A device may disappear and a new device may re-appear with the same device
node while the original device is suspended. Prevent a device resume to open
the wrong device.
In a path context, a changing syspath is the only indicator we get of the
device changing.
In a udev context, if the device was removed and libinput_dispatch() was
called, we can short-cut the syspath comparison by setting it to NULL.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c | 48 +++-
src/evdev.h | 4 +++-
src/path.c | 9 ++---
src/udev-seat.c | 4 +++-
4 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 78d9985..74632c8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -861,7 +861,8 @@ evdev_configure_device(struct evdev_device *device)
struct evdev_device *
evdev_device_create(struct libinput_seat *seat,
const char *devnode,
- const char *sysname)
+ const char *sysname,
+ const char *syspath)
{
struct libinput *libinput = seat-libinput;
struct evdev_device *device;
@@ -897,6 +898,7 @@ evdev_device_create(struct libinput_seat *seat,
device-mtdev = NULL;
device-devnode = strdup(devnode);
device-sysname = strdup(sysname);
+ device-syspath = strdup(syspath);
device-rel.dx = 0;
device-rel.dy = 0;
device-abs.seat_slot = -1;
@@ -1082,6 +1084,36 @@ evdev_device_suspend(struct evdev_device *device)
return 0;
}
+static int
+evdev_device_compare_syspath(struct evdev_device *device, int fd)
+{
+ struct udev *udev = NULL;
+ struct udev_device *udev_device = NULL;
+ const char *syspath;
+ struct stat st;
+ int rc = 1;
+
+ udev = udev_new();
+ if (!udev)
+ goto out;
+
+ if (fstat(fd, st) 0)
+ goto out;
+
+ udev_device = udev_device_new_from_devnum(udev, 'c', st.st_rdev);
+ if (!device)
+ goto out;
+
+ syspath = udev_device_get_syspath(udev_device);
+ rc = strcmp(syspath, device-syspath);
+out:
+ if (udev_device)
+ udev_device_unref(udev_device);
+ if (udev)
+ udev_unref(udev);
+ return rc;
+}
+
int
evdev_device_resume(struct evdev_device *device)
{
@@ -1091,11 +1123,19 @@ evdev_device_resume(struct evdev_device *device)
if (device-fd != -1)
return 0;
+ if (device-syspath == NULL)
+ return -ENODEV;
+
fd = open_restricted(libinput, device-devnode, O_RDWR | O_NONBLOCK);
if (fd 0)
return fd;
+ if (evdev_device_compare_syspath(device, fd)) {
+ close_restricted(libinput, fd);
+ return -ENODEV;
+ }
+
device-fd = fd;
device-source =
libinput_add_fd(libinput, fd, evdev_device_dispatch, device);
@@ -1110,6 +1150,11 @@ evdev_device_remove(struct evdev_device *device)
{
evdev_device_suspend(device);
+ /* A device may be removed while suspended. Free the syspath to
+* skip re-opening a different device with the same node */
+ free(device-syspath);
+ device-syspath = NULL;
+
list_remove(device-base.link);
notify_removed_device(device-base);
@@ -1131,5 +1176,6 @@ evdev_device_destroy(struct evdev_device *device)
free(device-mt.slots);
free(device-devnode);
free(device-sysname);
+ free(device-syspath);
free(device);
}
diff --git a/src/evdev.h b/src/evdev.h
index b4749b6..55fae4c 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -63,6 +63,7 @@ struct evdev_device {
char *output_name;
char *devnode;
char *sysname;
+ char *syspath;
const char *devname;
int fd;
struct {
@@ -126,7 +127,8 @@ struct evdev_dispatch {
struct evdev_device *
evdev_device_create(struct libinput_seat *seat,
const char *devnode,
- const char *sysname);
+ const char *sysname,
+ const char *syspath);
struct evdev_dispatch *
evdev_touchpad_create(struct evdev_device *device);
diff --git a/src/path.c b/src/path.c
index e9c0ee8..3752751 100644
--- a/src/path.c
+++ b/src/path.c
@@ -112,6 +112,7 @@ path_seat_get_named(struct path_input *input,
static int
path_get_udev_properties(const char *path,
char **sysname,
+char **syspath,
char **seat_name,
char **seat_logical_name)
{
@@ -133,6 +134,7 @@ path_get_udev_properties(const char *path,
goto out;
*sysname = strdup(udev_device_get_sysname(device));
+ *syspath = strdup(udev_device_get_syspath(device));
seat = udev_device_get_property_value(device, ID_SEAT);
*seat_name = strdup(seat ?
