Re: [PATCH weston 0/3] Rework the launcher infrastructure
Hi On Thu, Mar 19, 2015 at 4:04 AM, Jasper St. Pierre wrote: > Since the time that the logind launcher integration was written, it has > since gained a lot of features that mean that we don't have to touch > the TTY or VT ioctls ourselves. > > Refactor the launcher system so that we have three different > implementations of the launcher system, tried in this order: > > 1. logind, which uses the systemd-logind APIs to manage VTs and TTYs > and devices for us cooperatively. > > 2. weston-launch, which uses our legacy setuid helper to manage the > same devices. > > 3. Direct, which is only used when you are root, for small embedded > systems. > > The first two patches in this series should not have any major changes > in behavior, but is simply a giant refactor to make this code more > understandable and maintainable. > > The third patch upgrades our logind launcher to the latest APIs. > Switching to the new logind APIs on logind also adds the new ability > that a smoother handover can be done from display managers like gdm, > where we can have a VT allocated to us instead of requiring that we're > opened on our own VT. > > There should not be any regressions in existing behavior. > > Cc: David Herrmann > Cc: Ray Strode > > Jasper St. Pierre (3): > launcher: Rename logind-util to launcher-logind > launcher: Split out launcher implementations into three distinct ones > launcher-logind: Remove old VT switching code, move to > SwitchTo/Activate Looks good to me (especially the last one). I do have some suggestions to simplify some paths, but I don't think it's worth delaying this rework. This can all be done later on (and you mostly copied the code verbatim, anyway). Derek pointed out some issues, but apart from that I'm fine with the patches. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] compositor-fbdev: Wait and retry before failing on reconnect to the framebuffer
Hi On Fri, May 15, 2015 at 4:44 PM, Derek Foreman wrote: > On 15/05/15 05:30 AM, David Herrmann wrote: >> systemd-logind listens to VT events via poll(2) on >> /sys/class/tty/tty0/active. On VT switches it changes ACL permissions >> on dev-nodes underneath /dev, if the 'uaccess' tag is set on a device. >> But it cannot delay a VT-switch, it just reacts to it. >> >> It is inherent to this approach, that the permissions are set _after_ >> the VT switch. Therefore, there's a race and I guess it's what is hit >> here. However, systemd-logind sends out dbus signals after it fully >> changed the permissions. Hence, if you rely on the 'uaccess' >> functionality by systemd, then you better also use the systemd APIs >> (either sd_login_monitor_new() or DBus). If you don't want to use the >> systemd APIs, then you cannot rely on 'uaccess' (i.e., you have to set >> static group/user permissions on your device nodes; it will not >> interfere with 'uaccess', logind allows both in parallel). >> >> Long story short: Please run weston directly (_without_ weston-launch, >> instead directly invoking weston from within a logged-in VT), with >> systemd support compiled it. It should work fine with 'uaccess'. If >> you don't have systemd support compiled in, please use static access >> permissions. > > Does this mean weston-launch is always the wrong thing to do if systemd > support is compiled in? If systemd is running, weston-launch should probably execve() 'weston' directly without setting up WESTON_LAUNCHER_FD. > ie) should we refuse to build weston-launch if systemd support is enabled? This should be a run-time detection, not build-time, imho. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] compositor-fbdev: Wait and retry before failing on reconnect to the framebuffer
Hi
On Fri, May 15, 2015 at 8:39 AM, Pekka Paalanen wrote:
>
> On Wed, 13 May 2015 21:43:39 -0400
> nerdopolis wrote:
>
> > Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
> > udev might be configured to set the permissions on framebuffer devices with
> > the UACCESS attribute.
> > Weston currently attempts to reconnect to the framebuffer device before
> > udev can set the permissions back.
> >
> > It waits 3 times in case if the system is heavily paging, or slowed down,
> > and prevents udev from working.
> > In my testing the delay is long enough where it works on the first try
> > ---
> > src/compositor-fbdev.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> > index 7c505ce..42d2881 100644
> > --- a/src/compositor-fbdev.c
> > +++ b/src/compositor-fbdev.c
> > @@ -663,13 +663,23 @@ fbdev_output_reenable(struct fbdev_compositor
> > *compositor,
> > struct fbdev_output *output = to_fbdev_output(base);
> > struct fbdev_screeninfo new_screen_info;
> > int fb_fd;
> > + int retries;
> > const char *device;
> >
> > weston_log("Re-enabling fbdev output.\n");
> >
> > /* Create the frame buffer. */
> > - fb_fd = fbdev_frame_buffer_open(output, output->device,
> > + fb_fd = -1;
> > + retries = 0;
> > + while (fb_fd < 0 && retries < 3) {
> > + usleep(1);
> > + fb_fd = fbdev_frame_buffer_open(output, output->device,
> > &new_screen_info);
> > + if (fb_fd < 0) {
> > + weston_log("Creating frame buffer failed. Retrying...\n");
> > + }
> > + retries++;
> > + }
> > if (fb_fd < 0) {
> > weston_log("Creating frame buffer failed.\n");
> > goto err;
>
> Hi,
>
> I hate sleeps. I'd really want an explanation in the commit message on
> why this cannot be fixed properly at all, and you need a delay to have
> it work.
>
> It is possible there is no better way, but I would like to understand
> why first.
>
> For instance, should reenable() be waiting for some sort of udev
> advertisement of the fb device? Is there any event from udev to signal
> this?
>
> Do you have systemd involved in your use case? Could this be solved with
> systemd or logind? Or should we let weston-launch open the fb device
> instead?
>
> I'm CC'ing David, maybe he might have an idea?
systemd-logind listens to VT events via poll(2) on
/sys/class/tty/tty0/active. On VT switches it changes ACL permissions
on dev-nodes underneath /dev, if the 'uaccess' tag is set on a device.
But it cannot delay a VT-switch, it just reacts to it.
It is inherent to this approach, that the permissions are set _after_
the VT switch. Therefore, there's a race and I guess it's what is hit
here. However, systemd-logind sends out dbus signals after it fully
changed the permissions. Hence, if you rely on the 'uaccess'
functionality by systemd, then you better also use the systemd APIs
(either sd_login_monitor_new() or DBus). If you don't want to use the
systemd APIs, then you cannot rely on 'uaccess' (i.e., you have to set
static group/user permissions on your device nodes; it will not
interfere with 'uaccess', logind allows both in parallel).
Long story short: Please run weston directly (_without_ weston-launch,
instead directly invoking weston from within a logged-in VT), with
systemd support compiled it. It should work fine with 'uaccess'. If
you don't have systemd support compiled in, please use static access
permissions.
Thanks
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Set O_CLOEXEC when opening devices
Hi
On Thu, Apr 30, 2015 at 6:43 PM, Derek Foreman wrote:
> We'd rather keep these out of the hands of children.
>
> Signed-off-by: Derek Foreman
> ---
> src/evdev.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/src/evdev.c b/src/evdev.c
> index d997d24..af36127 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1953,7 +1953,8 @@ evdev_device_create(struct libinput_seat *seat,
> /* Use non-blocking mode so that we can loop on read on
> * evdev_device_data() until all events on the fd are
> * read. mtdev_get() also expects this. */
> - fd = open_restricted(libinput, devnode, O_RDWR | O_NONBLOCK);
> + fd = open_restricted(libinput, devnode,
> +O_RDWR | O_NONBLOCK | O_CLOEXEC);
> if (fd < 0) {
> log_info(libinput,
> "opening input device '%s' failed (%s).\n",
> @@ -2436,7 +2437,8 @@ evdev_device_resume(struct evdev_device *device)
> return -ENODEV;
>
> devnode = udev_device_get_devnode(device->udev_device);
> - fd = open_restricted(libinput, devnode, O_RDWR | O_NONBLOCK);
> + fd = open_restricted(libinput, devnode,
> +O_RDWR | O_NONBLOCK | O_CLOEXEC);
>
> if (fd < 0)
> return -errno;
> --
> 2.1.4
>
> ___
> 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 2/2] input: Set CLOEXEC on all opened fds
Hi On Thu, Apr 30, 2015 at 6:20 PM, Derek Foreman wrote: > We'd rather not have these fds available in all child processes, even > if using old versions of libinput that don't bother to set CLOEXEC > > Signed-off-by: Derek Foreman Reviewed-by: David Herrmann Thanks David > --- > src/libinput-seat.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/libinput-seat.c b/src/libinput-seat.c > index c0a87ea..6eae1a4 100644 > --- a/src/libinput-seat.c > +++ b/src/libinput-seat.c > @@ -186,7 +186,7 @@ open_restricted(const char *path, int flags, void > *user_data) > struct udev_input *input = user_data; > struct weston_launcher *launcher = input->compositor->launcher; > > - return weston_launcher_open(launcher, path, flags); > + return weston_launcher_open(launcher, path, flags | O_CLOEXEC); > } > > static void > -- > 2.1.4 > > ___ > 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 1/2] logind: actually close fd in weston_logind_close()
Hi On Thu, Apr 30, 2015 at 6:20 PM, Derek Foreman wrote: > You had one job... > > Signed-off-by: Derek Foreman > --- > src/logind-util.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/logind-util.c b/src/logind-util.c > index e4e20eb..1327b48 100644 > --- a/src/logind-util.c > +++ b/src/logind-util.c > @@ -248,6 +248,8 @@ weston_logind_close(struct weston_logind *wl, int fd) > > weston_logind_release_device(wl, major(st.st_rdev), > minor(st.st_rdev)); > + > + close(fd); You should really close the FD in the error-paths above, too. Or just go to launcher-util.c, weston_launcher_close() and drop the "return" before weston_logind_close(). Thanks David > } > > WL_EXPORT void > -- > 2.1.4 > > ___ > 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-launch: Fixed TTY switching
Hi
On Wed, Apr 8, 2015 at 2:03 AM, Bryce Harrington wrote:
> On Wed, Apr 01, 2015 at 08:10:44AM +0100, mateuszx.potr...@intel.com wrote:
>> From: Mateusz Polrola
>>
>> After weston-launch is executing weston it cannot close TTY file,
>> because it is still required to properly handle SIGUSR1 and SIGUSR2
>> signals that are used for switching TTY.
>>
>> Additionally after opening TTY it has to be activated, so that user
>> don't have to manually switch to TTY used by weston first to be able to
>> switch
>> to other TTY.
>> During shutdown TTY file has to be reopened, as device was already
>> deinitialize by child
>> process, but it is still required to cleanup VT handling and leave
>> system in sane state.
>>
>> Signed-off-by: Mateusz Polrola
>> ---
>> src/weston-launch.c | 20 +---
>> 1 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/weston-launch.c b/src/weston-launch.c
>> index 10c66de..312b955 100644
>> --- a/src/weston-launch.c
>> +++ b/src/weston-launch.c
>> @@ -46,6 +46,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -105,6 +106,7 @@ struct weston_launch {
>> pid_t child;
>> int verbose;
>> char *new_user;
>> + char tty_path[PATH_MAX];
>> };
>>
>> union cmsg_data { unsigned char b[4]; int fd; };
>> @@ -419,6 +421,13 @@ quit(struct weston_launch *wl, int status)
>> pam_end(wl->ph, err);
>> }
>>
>> + /* tty will be deinitialized by child process, so it has to be
>> + * opened again to correctly cleanup vt handling. */
>> + if (wl->tty != STDIN_FILENO) {
>> + close(wl->tty);
>> + wl->tty = open(wl->tty_path, O_RDWR | O_NOCTTY);
>> + }
>> +
Why this? I don't get why wl->tty is not good enough and you need to
reopen the fd.
>> if (ioctl(wl->tty, KDSKBMUTE, 0) &&
>> ioctl(wl->tty, KDSKBMODE, wl->kb_mode))
>> fprintf(stderr, "failed to restore keyboard mode: %m\n");
>> @@ -521,8 +530,10 @@ setup_tty(struct weston_launch *wl, const char *tty)
>> t = ttyname(STDIN_FILENO);
>> if (t && strcmp(t, tty) == 0)
>> wl->tty = STDIN_FILENO;
>> - else
>> + else {
>> wl->tty = open(tty, O_RDWR | O_NOCTTY);
>> + strcpy(wl->tty_path, tty);
>> + }
>
> I'm sure this is not going to ever be a problem since tty filenames and
> paths are on the short side, but since the tty string is an input
> parameter to this routine, it would be better defensive programming to
> use strncpy.
>
>> } else {
>> int tty0 = open("/dev/tty0", O_WRONLY | O_CLOEXEC);
>> char filename[16];
>> @@ -535,6 +546,7 @@ setup_tty(struct weston_launch *wl, const char *tty)
>>
>> snprintf(filename, sizeof filename, "/dev/tty%d", wl->ttynr);
>> wl->tty = open(filename, O_RDWR | O_NOCTTY);
>> + strcpy(wl->tty_path, filename);
>
> Since filename is set to a fixed length, I'm less worried about the
> strcpy here, but for code consistency you might use strncpy here as
> well.
>
>> close(tty0);
>> }
>>
>> @@ -555,6 +567,10 @@ setup_tty(struct weston_launch *wl, const char *tty)
>> wl->ttynr = minor(buf.st_rdev);
>> }
>>
>> + /* Activate tty, otherwise tty switches won't work right away. */
>> + ioctl(wl->tty, VT_ACTIVATE, wl->ttynr);
>> + ioctl(wl->tty, VT_WAITACTIVE, wl->ttynr);
>> +
>
> Check the ioctl returns and issue perror() on failure.
>
> Googling VT_WAITACTIVE shows misc. reports about it causing hangs in
> years past. No idea if that's at all likely here in Wayland. But if it
> is, it might be better to use a timed wait, checking the active tty each
> cycle, like was done in this fix:
>
> http://permalink.gmane.org/gmane.linux.kernel.suspend.devel/7119
Why do this at all? There is no reason to wait for the VT to become
active. Just issue the VT_ACTIVATE and continue, it's async and that's
good.
Btw., I'm no big fan of activating a VT when starting a compositor.
Xorg requires this as it cannot initialize in background, but new
compositors should really support this. Imagine you're started by a
login-manager. You really want the compositor to initialize in
background and wait to be switched to by the login manager.
Yes, weston-launch is special, as it is its own login-manager. So I'd
be fine with the VT_ACTIVATE. But i cannot see why we'd need
VT_WAITACTIVE?
>> if (ioctl(wl->tty, KDGKBMODE, &wl->kb_mode))
>> error(1, errno, "failed to get current keyboard mode: %m\n");
>>
>> @@ -744,8 +760,6 @@ main(int argc, char *argv[])
>> launch_compositor(&wl, argc - optind, argv + optind);
>>
>> close(wl.sock[1]);
>> - if (wl.tty != STDIN_FILENO)
>> - close(wl.tty);
>
> I'm having some trouble following the move of the close logic. I trust
> w
Re: [RFC v2 libinput 0/2] Buttonset interface - numbered axes
Hi On Wed, Mar 18, 2015 at 7:58 AM, Peter Hutterer wrote: > > This is a re-vamped version of the buttonset interface. Still WIP but I'd > like to get some comments on the API. > > Changes to the last version: > This version now uses numbered axes instead of typed axes. Previously the > interface used a unique axis type to deal with axes (e.g. > LIBINPUT_BUTTONSET_AXIS_RING_LEFT). This approach was ditched, instead a > device has a number of axes, each with a type. A caller can check how many > axes are there and the type for each axis. In the event interface, the axis > number is used, not the type. > > A whole bunch of axes have been added too though the wacom pad interface > doesn't expose them, only wheel and ring. > > Branch is available here: > https://github.com/whot/libinput/tree/wip/buttonbox-interface > > It's still missing a couple of details, tests, checks, etc. but it should > show the interface well enough. Awesome! Really appreciated! Few assorted comments: 1) You introduce an enum for axis-types, instead of using the ABS_* and REL_* values. On purpose? What's the reason? You don't do this for buttons. I can come up with several reasons, but a clear statement would be nice: - you want to merge ABS_* and REL_* into a single namespace - you want to get rid of the ABS_X/Y/Z and ABS_HAT* misuse for anything that doesn't have its own ABS_* type - ABS2_* still didn't land upstream, so there's no way to introduce new ABS_* values, but we really need them (yeah, my bad, I know!) - the kernel ABS_* values just never made any sense 2) Mapping from ABS_*/REL_* to axis-types is static? That is, we do this based on the devices we know, instead of a magic translation table for all types. I really like this, as we can get rid of the crappy mappings we used to have for gamepads and so on. I just wonder why this isn't done for buttons. Yeah, the namespace is bigger for buttons and it used to have less bad mappings, but they still exist. 3) What is an axis-source? I don't get it. What else should I use to control an axis, but my finger? My tongue? :) Ok, seriously, the description is a bit short. Is this meant to distinguish between touch-based input and other input? So you get release-events for the 'finger'-based input? 4) Why hard-code 'relative' in the axis-name, instead of making it a property? AXIS_X/Y/Z and ROTATION_X/Y/Z already are two examples that can be absolute _and_ relative. Wouldn't it make sense to make 'relative' a boolean attribute of an axis on a device? I don't know what RING and STRIP is, so cannot comment on that. A lot of other axes have this implicit (accelerometer/gyro/compass are always absolute, for instance), so not sure it's a good idea. Just wanted to bring it up and see whether you have any input on it. 5) If a device has multiple axes of the same type, is the order supposed to be ABI? Example: gamepads tend to have two analog-sticks. How do applications reliably find the left and right stick? 6) *_get_*_transformed() is linear? Can you mention that in the description? It's not clear just from the name 'transform' and a min/max range. 7) libinput_event_buttonset_get_axis_delta_transformed()? What is that thing doing? libinput_event_buttonset_get_axis_delta() returns data for relative axes, but the *_transformed() version says it always returns 0 for relative axes? There's a big FIXME, but the function description doesn't make sense to me. Can you elaborate? 8) What is libinput_event_buttonset_get_seat_button_count() good for? Not that I care much, but it made me curious :) 9) There's only libinput_device_buttonset_has_button(), but no way to get a list of buttons enabled on that device. Do you expect applications to iterate all 2^32 buttons or are applications not supposed to retrieve the set of buttons on a device? Last point: Will there be some generic type for libinput-devices so applications can select them? For instance: "this is a wacom-tablet-style-thing" or "this is a gamepad", .. etc. Or are applications supposed to look exactly at the capabilities of a device and say "Hey, this has two analog-sticks, a dpad, 4 action-buttons and a bit more; lets use it as gamepad input"? I like the latter, but wanna be sure what the plans are. Again, much appreciated! If this lands upstream, it'd be definitely worth a look to add gamepad/etc. support. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/4] logind: fix PropertiesChanged parser
The current parser directly reads a BOOLEAN on the PropertiesChanged
signal for 'Active' properties. However, all property-values are packed in
a VARIANT, otherwise, we wouldn't know the type. Fix the parser to recurse
into the variant before reading the boolean.
To avoid such bugs in the future, we extract the 'Active' parser into a
helper function parse_active(), which is then shared between the
PropertiesChanged and Get handlers.
Signed-off-by: David Herrmann
---
src/logind-util.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/src/logind-util.c b/src/logind-util.c
index db23606..e4e20eb 100644
--- a/src/logind-util.c
+++ b/src/logind-util.c
@@ -287,33 +287,18 @@ weston_logind_set_active(struct weston_logind *wl, bool
active)
}
static void
-get_active_cb(DBusPendingCall *pending, void *data)
+parse_active(struct weston_logind *wl, DBusMessage *m, DBusMessageIter *iter)
{
- struct weston_logind *wl = data;
- DBusMessage *m;
- DBusMessageIter iter, sub;
- int type;
+ DBusMessageIter sub;
dbus_bool_t b;
- dbus_pending_call_unref(wl->pending_active);
- wl->pending_active = NULL;
-
- m = dbus_pending_call_steal_reply(pending);
- if (!m)
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_VARIANT)
return;
- type = dbus_message_get_type(m);
- if (type != DBUS_MESSAGE_TYPE_METHOD_RETURN)
- goto err_unref;
-
- if (!dbus_message_iter_init(m, &iter) ||
- dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_VARIANT)
- goto err_unref;
-
- dbus_message_iter_recurse(&iter, &sub);
+ dbus_message_iter_recurse(iter, &sub);
if (dbus_message_iter_get_arg_type(&sub) != DBUS_TYPE_BOOLEAN)
- goto err_unref;
+ return;
dbus_message_iter_get_basic(&sub, &b);
@@ -322,8 +307,28 @@ get_active_cb(DBusPendingCall *pending, void *data)
* other backends, we immediately forward the Active-change event. */
if (!wl->sync_drm || !b)
weston_logind_set_active(wl, b);
+}
+
+static void
+get_active_cb(DBusPendingCall *pending, void *data)
+{
+ struct weston_logind *wl = data;
+ DBusMessageIter iter;
+ DBusMessage *m;
+ int type;
+
+ dbus_pending_call_unref(wl->pending_active);
+ wl->pending_active = NULL;
+
+ m = dbus_pending_call_steal_reply(pending);
+ if (!m)
+ return;
+
+ type = dbus_message_get_type(m);
+ if (type == DBUS_MESSAGE_TYPE_METHOD_RETURN &&
+ dbus_message_iter_init(m, &iter))
+ parse_active(wl, m, &iter);
-err_unref:
dbus_message_unref(m);
}
@@ -408,7 +413,6 @@ property_changed(struct weston_logind *wl, DBusMessage *m)
{
DBusMessageIter iter, sub, entry;
const char *interface, *name;
- dbus_bool_t b;
if (!dbus_message_iter_init(m, &iter) ||
dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
@@ -433,12 +437,8 @@ property_changed(struct weston_logind *wl, DBusMessage *m)
goto error;
if (!strcmp(name, "Active")) {
- if (dbus_message_iter_get_arg_type(&entry) ==
DBUS_TYPE_BOOLEAN) {
- dbus_message_iter_get_basic(&entry, &b);
- if (!b)
- weston_logind_set_active(wl, false);
- return;
- }
+ parse_active(wl, m, &entry);
+ return;
}
dbus_message_iter_next(&sub);
--
2.2.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/4] logind: use SIGRTMIN to not conflict with xwayland
xwayland uses SIGUSR1 as startup notification. Make sure to use SIGRTMIN
and SIGRTMIN+1 for VT handling.
A bonus is SIGRT* signals can be queued multiple times, so we will be able
to correctly track them and will no longer loose signals (which wouldn't
really matter, but is confusing in logs).
Signed-off-by: David Herrmann
---
src/logind-util.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/src/logind-util.c b/src/logind-util.c
index 554e64d..132a9a2 100644
--- a/src/logind-util.c
+++ b/src/logind-util.c
@@ -692,14 +692,10 @@ signal_event(int fd, uint32_t mask, void *data)
return 0;
}
- switch (sig.ssi_signo) {
- case SIGUSR1:
+ if (sig.ssi_signo == (unsigned int)SIGRTMIN)
ioctl(wl->vt, VT_RELDISP, 1);
- break;
- case SIGUSR2:
+ else if (sig.ssi_signo == (unsigned int)SIGRTMIN + 1)
ioctl(wl->vt, VT_RELDISP, VT_ACKACQ);
- break;
- }
return 0;
}
@@ -767,9 +763,21 @@ weston_logind_setup_vt(struct weston_logind *wl)
goto err_kbmode;
}
+ /*
+* SIGRTMIN is used as global VT-release signal, SIGRTMIN + 1 is used
+* as VT-acquire signal. Note that SIGRT* must be tested on runtime, as
+* their exact values are not known at compile-time. POSIX requires 32
+* of them to be available, though.
+*/
+ if (SIGRTMIN + 1 > SIGRTMAX) {
+ weston_log("logind: not enough RT signals available: %u-%u\n",
+ SIGRTMIN, SIGRTMAX);
+ return -EINVAL;
+ }
+
sigemptyset(&mask);
- sigaddset(&mask, SIGUSR1);
- sigaddset(&mask, SIGUSR2);
+ sigaddset(&mask, SIGRTMIN);
+ sigaddset(&mask, SIGRTMIN + 1);
sigprocmask(SIG_BLOCK, &mask, NULL);
wl->sfd = signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC);
@@ -790,8 +798,8 @@ weston_logind_setup_vt(struct weston_logind *wl)
}
mode.mode = VT_PROCESS;
- mode.relsig = SIGUSR1;
- mode.acqsig = SIGUSR2;
+ mode.relsig = SIGRTMIN;
+ mode.acqsig = SIGRTMIN + 1;
if (ioctl(wl->vt, VT_SETMODE, &mode) < 0) {
r = -errno;
weston_log("logind: cannot take over VT: %m\n");
--
2.2.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/4] logind: forward Active=true changes for non-DRM backends
Logind sends us notification whenever the Active attribute of our session
changes. However, due to the way compositor-drm.c relies on the master DRM
device to be synced with the session, we used to delay Active=true
handling until the DRM device was up, too. See:
commit aedc7732ebd9bc7b4f51ee247ea857ffec6260a7
Author: David Herrmann
Date: Sat Nov 30 11:25:45 2013 +0100
logind: delay wakeup until DRM-device is resumed
However, the other compositor backends do not use DRM, so logind-util will
never get notified about any DRM device. Therefore, we have to forward the
Active=true change immediately.
This commit fixes logind-util to take sync_drm as argument. If it is true,
we do DRM-device synchronisation, otherwise we don't.
Signed-off-by: David Herrmann
---
src/compositor-drm.c | 2 +-
src/compositor-fbdev.c | 5 +++--
src/compositor-rpi.c | 5 +++--
src/launcher-util.c| 4 ++--
src/launcher-util.h| 2 +-
src/logind-util.c | 16 +++-
src/logind-util.h | 4 ++--
7 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 9b4d4dc..4473254 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2774,7 +2774,7 @@ drm_compositor_create(struct wl_display *display,
/* Check if we run drm-backend using weston-launch */
ec->base.launcher = weston_launcher_connect(&ec->base, param->tty,
- param->seat_id);
+ param->seat_id, true);
if (ec->base.launcher == NULL) {
weston_log("fatal: drm backend should be run "
"using weston-launch binary or as root\n");
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 65bb035..805a195 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -891,8 +891,9 @@ fbdev_compositor_create(struct wl_display *display, int
*argc, char *argv[],
compositor->session_listener.notify = session_notify;
wl_signal_add(&compositor->base.session_signal,
&compositor->session_listener);
- compositor->base.launcher =
- weston_launcher_connect(&compositor->base, param->tty, "seat0");
+ compositor->base.launcher = weston_launcher_connect(&compositor->base,
+ param->tty, "seat0",
+ false);
if (!compositor->base.launcher) {
weston_log("fatal: fbdev backend should be run "
"using weston-launch binary or as root\n");
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 150e9e1..a064a86 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -480,8 +480,9 @@ rpi_compositor_create(struct wl_display *display, int
*argc, char *argv[],
compositor->session_listener.notify = session_notify;
wl_signal_add(&compositor->base.session_signal,
&compositor ->session_listener);
- compositor->base.launcher =
- weston_launcher_connect(&compositor->base, param->tty, "seat0");
+ compositor->base.launcher = weston_launcher_connect(&compositor->base,
+ param->tty, "seat0",
+ false);
if (!compositor->base.launcher) {
weston_log("Failed to initialize tty.\n");
goto out_udev;
diff --git a/src/launcher-util.c b/src/launcher-util.c
index ad81aef..e89710b 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -386,7 +386,7 @@ weston_launcher_activate_vt(struct weston_launcher
*launcher, int vt)
struct weston_launcher *
weston_launcher_connect(struct weston_compositor *compositor, int tty,
- const char *seat_id)
+ const char *seat_id, bool sync_drm)
{
struct weston_launcher *launcher;
struct wl_event_loop *loop;
@@ -418,7 +418,7 @@ weston_launcher_connect(struct weston_compositor
*compositor, int tty,
}
} else {
r = weston_logind_connect(&launcher->logind, compositor,
- seat_id, tty);
+ seat_id, tty, sync_drm);
if (r < 0) {
launcher->logind = NULL;
if (geteuid() == 0) {
diff --git a/src/launcher-util.h b/src/launcher-util.h
index d5b2fc9..a60f8a1 100644
--- a/src/launcher-util.h
+++ b/src/launcher-util.h
@@ -31,7 +31,7 @@ struct weston_launcher;
struct weston_launche
[PATCH weston 2/4] launcher: use SIGRTMIN to not conflict with xwayland
xwayland uses SIGUSR1 as startup notification. Make sure to use SIGRTMIN
for VT handling to avoid conflicts.
A bonus is SIGRT* signals can be queued multiple times, so we will be able
to correctly track them and will no longer loose signals (which wouldn't
really matter, but is confusing in logs).
Signed-off-by: David Herrmann
---
src/launcher-util.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/launcher-util.c b/src/launcher-util.c
index ac764dc..ad81aef 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -342,9 +342,21 @@ setup_tty(struct weston_launcher *launcher, int tty)
goto err_close;
}
+ /*
+* SIGRTMIN is used as global VT-acquire+release signal. Note that
+* SIGRT* must be tested on runtime, as their exact values are not
+* known at compile-time. POSIX requires 32 of them to be available.
+*/
+ if (SIGRTMIN > SIGRTMAX) {
+ weston_log("not enough RT signals available: %u-%u\n",
+ SIGRTMIN, SIGRTMAX);
+ ret = -EINVAL;
+ goto err_close;
+ }
+
mode.mode = VT_PROCESS;
- mode.relsig = SIGUSR1;
- mode.acqsig = SIGUSR1;
+ mode.relsig = SIGRTMIN;
+ mode.acqsig = SIGRTMIN;
if (ioctl(launcher->tty, VT_SETMODE, &mode) < 0) {
weston_log("failed to take control of vt handling\n");
goto err_close;
@@ -352,7 +364,7 @@ setup_tty(struct weston_launcher *launcher, int tty)
loop = wl_display_get_event_loop(launcher->compositor->wl_display);
launcher->vt_source =
- wl_event_loop_add_signal(loop, SIGUSR1, vt_handler, launcher);
+ wl_event_loop_add_signal(loop, SIGRTMIN, vt_handler, launcher);
if (!launcher->vt_source)
goto err_close;
--
2.2.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/1] weston-launch: alter tty command line parameter semantics
Hi On Tue, Dec 16, 2014 at 9:19 AM, Daniel Stone wrote: >> I reasoned that user access to the tty should be set up by the kernel >> policies, and we should not enforce the policy at weston level. If the >> system is configured in this way, then a user with enough permissions can >> start up weston under his account without having to have root permissions. >> >> >> In the end, I can use the openvt workaround, if you are concerned about >> the security implications. > > > Well, given that weston-launch is suid and opens the device on behalf of > weston, you're actually bypassing all of the kernel policies and > enforcement, since the kernel will just see root attempting to open it. This > is what makes me nervous. Previously weston-launch would only allow > arbitrary TTY selection if you were actually root (user can only be set when > getuid() == geteuid()), but this change allows any user with weston-launch > access to open any VT that root can access. > > I could definitely be swayed, but in the absence of someone who knows > definitively whether or not this is a good idea (David?), I'd lean towards > not changing the current behaviour - except to produce an error message when > --tty is specified but not --user. So far VT allocation was left to your login-manager and you shouldn't mess with it. The openvt-logic (whether that is 'openvt' or 'VT_OPENQRY') is meant as workaround for people who want minimal login-managers (or rather no login-manager at all). So if we can avoid supporting any more sophisticated options, I'd welcome that. So I agree with Daniel here. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Fix bug https://bugs.freedesktop.org/show_bug.cgi?id=86889 by emitting session signals on TTY switches so that the weston backends can handle VT switching when not called from weston-launc
Hi
On Mon, Dec 15, 2014 at 11:04 AM, Pekka Paalanen wrote:
> On Sun, 07 Dec 2014 10:15:29 -0500
> nerdopolis wrote:
>
>> ---
>> src/logind-util.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/src/logind-util.c b/src/logind-util.c
>> index 6a1b498..4308bb6 100644
>> --- a/src/logind-util.c
>> +++ b/src/logind-util.c
>> @@ -695,9 +695,15 @@ signal_event(int fd, uint32_t mask, void *data)
>> switch (sig.ssi_signo) {
>> case SIGUSR1:
>> ioctl(wl->vt, VT_RELDISP, 1);
>> + wl->compositor->session_active=0;
>> + wl_signal_emit(&wl->compositor->session_signal,
>> +wl->compositor);
>> break;
>> case SIGUSR2:
>> ioctl(wl->vt, VT_RELDISP, VT_ACKACQ);
>> + wl->compositor->session_active=1;
>> + wl_signal_emit(&wl->compositor->session_signal,
>> +wl->compositor);
>> break;
>> }
>>
>
> Hi,
>
> reading the commit
> http://cgit.freedesktop.org/wayland/weston/commit/?id=aedc7732ebd9bc7b4f51ee247ea857ffec6260a7
> I'm not too sure this patch is right.
>
> David, would you mind taking a look?
This patch breaks compositor-drm.c, indeed. The underlying problem is
the way compositor-drm was written (by relying on the DRM device to
define session status). As that is non-trivial to change,
logind-util.c syns session state with the master DRM device.
I wrote a patch that should fix this issue for !DRM backends. I also
attached the patch in case the inlined version is whitespace damaged.
Thanks
David
>From 9b487b2177633c86f934ad3e682910e777d7b543 Mon Sep 17 00:00:00 2001
From: David Herrmann
Date: Mon, 15 Dec 2014 13:34:35 +0100
Subject: [PATCH] logind: forward Active=true changes for non-DRM backends
Logind sends us notification whenever the Active attribute of our session
changes. However, due to the way compositor-drm.c relies on the master DRM
device to be synced with the session, we used to delay Active=true
handling until the DRM device was up, too. See:
commit aedc7732ebd9bc7b4f51ee247ea857ffec6260a7
Author: David Herrmann
Date: Sat Nov 30 11:25:45 2013 +0100
logind: delay wakeup until DRM-device is resumed
However, the other compositor backends do not use DRM, so logind-util will
never get notified about any DRM device. Therefore, we have to forward the
Active=true change immediately.
This commit fixes logind-util to take sync_drm as argument. If it is true,
we do DRM-device synchronisation, otherwise we don't.
Signed-off-by: David Herrmann
---
src/compositor-drm.c | 2 +-
src/compositor-fbdev.c | 5 +++--
src/compositor-rpi.c | 5 +++--
src/launcher-util.c| 4 ++--
src/launcher-util.h| 2 +-
src/logind-util.c | 12 +---
src/logind-util.h | 4 ++--
7 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 9b4d4dc..4473254 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2774,7 +2774,7 @@ drm_compositor_create(struct wl_display *display,
/* Check if we run drm-backend using weston-launch */
ec->base.launcher = weston_launcher_connect(&ec->base, param->tty,
-param->seat_id);
+param->seat_id, true);
if (ec->base.launcher == NULL) {
weston_log("fatal: drm backend should be run "
"using weston-launch binary or as root\n");
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 65bb035..805a195 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -891,8 +891,9 @@ fbdev_compositor_create(struct wl_display
*display, int *argc, char *argv[],
compositor->session_listener.notify = session_notify;
wl_signal_add(&compositor->base.session_signal,
&compositor->session_listener);
- compositor->base.launcher =
- weston_launcher_connect(&compositor->base, param->tty, "seat0");
+ compositor->base.launcher = weston_launcher_connect(&compositor->base,
+param->tty, "seat0",
+false);
if (!compositor->base.launcher) {
weston_log("fatal: fbdev backend should be run "
"using weston-launch binary or as root\n");
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 150e9e1..a064a86 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -480,8 +480,9 @@ rpi_compositor_create(struct wl_display *display,
int *argc, char *argv[],
compositor->session_listener.notify = session_notify;
wl_signal_add(&compositor->base.session_signal,
&compositor ->session_listener);
- compositor->base.launcher =
- weston_launcher_connect(&compositor->ba
Re: [PATCH v3 libinput] util: introduce ratelimit helpers
Hi
On Thu, Nov 6, 2014 at 11:39 PM, Peter Hutterer
wrote:
> From: David Herrmann
>
> This adds "struct ratelimit" and "ratelimit_test()". It's a very simple
> rate-limit helper modeled after Linux' lib/ratelimit.c by Dave Young.
>
> This comes in handy to limit log-messages in possible busy loops etc..
>
> Signed-off-by: David Herrmann
> Reviewed-by: Peter Hutterer
> Signed-off-by: Peter Hutterer
> ---
> The test succeeded but not in valgrind which slows everything down enough
> that we didn't trigger the rate limit (valgrind is part of make check). I
> though of adding extra flags to detect when we're running valgrind but it's
> simpler to just extend the timeouts a bit.
> So instead of 10 msg per 10ms it's 10 per 100ms, the wait is 20ms and then
> another 90ms to go definitely above the 100ms.
> And only loop three times, otherwise we trigger the generic test timeout
> detection.
>
> Changes to v3:
> - ck_assert(a == b) -> ck_assert_int_eq(a, b)
> - timeouts tweaked to avoid test failures when running through valgrind
Wow, I'm no longer the one with the slowest laptop! ;)
Btw., the ck_assert_*() helpers are the bottleneck, not valgrind (at
least that's my guess based on previous performance-problems with
ck_assert). So we could maybe also try something like:
if (!$condition)
ck_assert($condition);
That fixed my code last time, but totally untested and maybe libcheck
does that automatically now. Your patch is fine, too. No objections
from my side.
Thanks
David
> src/libinput-util.c | 48
> src/libinput-util.h | 16
> test/misc.c | 42 ++
> 3 files changed, 106 insertions(+)
>
> diff --git a/src/libinput-util.c b/src/libinput-util.c
> index eeb9786..34d5549 100644
> --- a/src/libinput-util.c
> +++ b/src/libinput-util.c
> @@ -65,3 +65,51 @@ list_empty(const struct list *list)
> {
> return list->next == list;
> }
> +
> +void
> +ratelimit_init(struct ratelimit *r, uint64_t ival_ms, unsigned int burst)
> +{
> + r->interval = ival_ms;
> + r->begin = 0;
> + r->burst = burst;
> + r->num = 0;
> +}
> +
> +/*
> + * Perform rate-limit test. Returns RATELIMIT_PASS if the rate-limited action
> + * is still allowed, RATELIMIT_THRESHOLD if the limit has been reached with
> + * this call, and RATELIMIT_EXCEEDED if you're beyond the threshold.
> + * It's safe to treat the return-value as boolean, if you're not interested
> in
> + * the exact state. It evaluates to "true" if the threshold hasn't been
> + * exceeded, yet.
> + *
> + * The ratelimit object must be initialized via ratelimit_init().
> + *
> + * Modelled after Linux' lib/ratelimit.c by Dave Young
> + * , which is licensed GPLv2.
> + */
> +enum ratelimit_state
> +ratelimit_test(struct ratelimit *r)
> +{
> + struct timespec ts;
> + uint64_t mtime;
> +
> + if (r->interval <= 0 || r->burst <= 0)
> + return RATELIMIT_PASS;
> +
> + clock_gettime(CLOCK_MONOTONIC, &ts);
> + mtime = ts.tv_sec * 1000 + ts.tv_nsec / 1000 / 1000;
> +
> + if (r->begin <= 0 || r->begin + r->interval < mtime) {
> + /* reset counter */
> + r->begin = mtime;
> + r->num = 1;
> + return RATELIMIT_PASS;
> + } else if (r->num < r->burst) {
> + /* continue burst */
> + return (++r->num == r->burst) ? RATELIMIT_THRESHOLD
> + : RATELIMIT_PASS;
> + }
> +
> + return RATELIMIT_EXCEEDED;
> +}
> diff --git a/src/libinput-util.h b/src/libinput-util.h
> index 51759e8..909c9db 100644
> --- a/src/libinput-util.h
> +++ b/src/libinput-util.h
> @@ -280,4 +280,20 @@ matrix_to_farray6(const struct matrix *m, float out[6])
> out[5] = m->val[1][2];
> }
>
> +enum ratelimit_state {
> + RATELIMIT_EXCEEDED,
> + RATELIMIT_THRESHOLD,
> + RATELIMIT_PASS,
> +};
> +
> +struct ratelimit {
> + uint64_t interval;
> + uint64_t begin;
> + unsigned int burst;
> + unsigned int num;
> +};
> +
> +void ratelimit_init(struct ratelimit *r, uint64_t ival_ms, unsigned int
> burst);
> +enum ratelimit_state ratelimit_test(struct ratelimit *r);
> +
> #endif /* LIBINPUT_UTIL_H */
> diff --git a/test/misc.c b/test/misc.c
> index 1512180..38320f3 100644
> --- a/test/misc.c
> +++ b/test/misc.c
&g
Re: [PATCH libinput v2 1/2] util: introduce ratelimit helpers
Hi
On Thu, Nov 6, 2014 at 6:51 AM, Peter Hutterer wrote:
> On Wed, Nov 05, 2014 at 01:32:16PM +0100, David Herrmann wrote:
>> diff --git a/test/misc.c b/test/misc.c
>> index 1512180..aa411ec 100644
>> --- a/test/misc.c
>> +++ b/test/misc.c
>> @@ -508,6 +508,40 @@ START_TEST(matrix_helpers)
>> }
>> END_TEST
>>
>> +START_TEST(ratelimit_helpers)
>> +{
>> + struct ratelimit rl;
>> + unsigned int i, j;
>> +
>> + /* 10 attempts every 10ms */
>> + ratelimit_init(&rl, 10, 10);
>> +
>> + for (j = 0; j < 100; ++j) {
>> + /* a burst of 9 attempts must succeed */
>> + for (i = 0; i < 9; ++i)
>> + ck_assert(ratelimit_test(&rl) == RATELIMIT_PASS);
>> +
>> + /* the 10th attempt reaches the threshold */
>> + ck_assert(ratelimit_test(&rl) == RATELIMIT_THRESHOLD);
>
> merged both, with changes to ck_assert_int_eq:
> ck_assert_int_eq(ratelimit_test(&rl), RATELIMIT_THRESHOLD);
>
> a bit quicker to debug when it fails, the error message will print both
> values so you get an idea of what the mismatch is.
Whoops, yeah, totally forgot about the other ck_assert_* macros.
Thanks for amending the changes!
Thanks
David
> thanks
>
> Cheers,
>Peter
>
>
>> +
>> + /* ..then further attempts must fail.. */
>> + ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
>> +
>> + /* ..regardless of how often we try. */
>> + for (i = 0; i < 100; ++i)
>> + ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
>> +
>> + /* ..even after waiting 5ms */
>> + msleep(5);
>> + for (i = 0; i < 100; ++i)
>> + ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
>> +
>> + /* but after 10ms the counter is reset */
>> + msleep(6); /* +1ms to account for time drifts */
>> + }
>> +}
>> +END_TEST
>> +
>> int main (int argc, char **argv) {
>> litest_add_no_device("events:conversion",
>> event_conversion_device_notify);
>> litest_add_no_device("events:conversion", event_conversion_pointer);
>> @@ -519,5 +553,7 @@ int main (int argc, char **argv) {
>> litest_add_no_device("config:status string", config_status_string);
>>
>> litest_add_no_device("misc:matrix", matrix_helpers);
>> + litest_add_no_device("misc:ratelimit", ratelimit_helpers);
>> +
>> return litest_run(argc, argv);
>> }
>> --
>> 2.1.3
>>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput v2 2/2] evdev: ratelimit SYN_DROPPED logging
Use the ratelimit helpers for SYN_DROPPED logging. This guarantees that we
will still receive SYN_DROPPED log-messages after multiple days of
runtime, even though there might have been a SYN_DROPPED flood at one
point in time.
Signed-off-by: David Herrmann
---
src/evdev.c | 18 --
src/evdev.h | 4 +---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 3aa87a7..0e2d54d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -926,15 +926,19 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device->evdev,
LIBEVDEV_READ_FLAG_NORMAL, &ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
- if (device->syn_drops_received < 10) {
- device->syn_drops_received++;
+ switch (ratelimit_test(&device->syn_drop_limit)) {
+ case RATELIMIT_PASS:
log_info(libinput, "SYN_DROPPED event from "
"\"%s\" - some input events have "
"been lost.\n", device->devname);
- if (device->syn_drops_received == 10)
- log_info(libinput, "No longer logging "
-"SYN_DROPPED events for "
-"\"%s\"\n", device->devname);
+ break;
+ case RATELIMIT_THRESHOLD:
+ log_info(libinput, "SYN_DROPPED flood "
+"from \"%s\"\n",
+device->devname);
+ break;
+ case RATELIMIT_EXCEEDED:
+ break;
}
/* send one more sync event so we handle all
@@ -1296,6 +1300,8 @@ evdev_device_create(struct libinput_seat *seat,
device->scroll.threshold = 5.0; /* Default may be overridden */
device->scroll.direction = 0;
device->dpi = DEFAULT_MOUSE_DPI;
+ /* at most 5 SYN_DROPPED log-messages per 30s */
+ ratelimit_init(&device->syn_drop_limit, 30ULL * 1000, 5);
matrix_init_identity(&device->abs.calibration);
matrix_init_identity(&device->abs.usermatrix);
diff --git a/src/evdev.h b/src/evdev.h
index 666c8dc..eefbb79 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -137,9 +137,7 @@ struct evdev_device {
} buttons;
int dpi; /* HW resolution */
- /* The number of times libevdev processes a SYN_DROPPED, so we can
-* stop logging them to avoid flooding the logs. */
- int syn_drops_received;
+ struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
};
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput v2 1/2] util: introduce ratelimit helpers
This adds "struct ratelimit" and "ratelimit_test()". It's a very simple
rate-limit helper modeled after Linux' lib/ratelimit.c by Dave Young.
This comes in handy to limit log-messages in possible busy loops etc..
Signed-off-by: David Herrmann
---
src/libinput-util.c | 48
src/libinput-util.h | 16
test/misc.c | 36
3 files changed, 100 insertions(+)
diff --git a/src/libinput-util.c b/src/libinput-util.c
index eeb9786..34d5549 100644
--- a/src/libinput-util.c
+++ b/src/libinput-util.c
@@ -65,3 +65,51 @@ list_empty(const struct list *list)
{
return list->next == list;
}
+
+void
+ratelimit_init(struct ratelimit *r, uint64_t ival_ms, unsigned int burst)
+{
+ r->interval = ival_ms;
+ r->begin = 0;
+ r->burst = burst;
+ r->num = 0;
+}
+
+/*
+ * Perform rate-limit test. Returns RATELIMIT_PASS if the rate-limited action
+ * is still allowed, RATELIMIT_THRESHOLD if the limit has been reached with
+ * this call, and RATELIMIT_EXCEEDED if you're beyond the threshold.
+ * It's safe to treat the return-value as boolean, if you're not interested in
+ * the exact state. It evaluates to "true" if the threshold hasn't been
+ * exceeded, yet.
+ *
+ * The ratelimit object must be initialized via ratelimit_init().
+ *
+ * Modelled after Linux' lib/ratelimit.c by Dave Young
+ * , which is licensed GPLv2.
+ */
+enum ratelimit_state
+ratelimit_test(struct ratelimit *r)
+{
+ struct timespec ts;
+ uint64_t mtime;
+
+ if (r->interval <= 0 || r->burst <= 0)
+ return RATELIMIT_PASS;
+
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+ mtime = ts.tv_sec * 1000 + ts.tv_nsec / 1000 / 1000;
+
+ if (r->begin <= 0 || r->begin + r->interval < mtime) {
+ /* reset counter */
+ r->begin = mtime;
+ r->num = 1;
+ return RATELIMIT_PASS;
+ } else if (r->num < r->burst) {
+ /* continue burst */
+ return (++r->num == r->burst) ? RATELIMIT_THRESHOLD
+ : RATELIMIT_PASS;
+ }
+
+ return RATELIMIT_EXCEEDED;
+}
diff --git a/src/libinput-util.h b/src/libinput-util.h
index 51759e8..909c9db 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -280,4 +280,20 @@ matrix_to_farray6(const struct matrix *m, float out[6])
out[5] = m->val[1][2];
}
+enum ratelimit_state {
+ RATELIMIT_EXCEEDED,
+ RATELIMIT_THRESHOLD,
+ RATELIMIT_PASS,
+};
+
+struct ratelimit {
+ uint64_t interval;
+ uint64_t begin;
+ unsigned int burst;
+ unsigned int num;
+};
+
+void ratelimit_init(struct ratelimit *r, uint64_t ival_ms, unsigned int burst);
+enum ratelimit_state ratelimit_test(struct ratelimit *r);
+
#endif /* LIBINPUT_UTIL_H */
diff --git a/test/misc.c b/test/misc.c
index 1512180..aa411ec 100644
--- a/test/misc.c
+++ b/test/misc.c
@@ -508,6 +508,40 @@ START_TEST(matrix_helpers)
}
END_TEST
+START_TEST(ratelimit_helpers)
+{
+ struct ratelimit rl;
+ unsigned int i, j;
+
+ /* 10 attempts every 10ms */
+ ratelimit_init(&rl, 10, 10);
+
+ for (j = 0; j < 100; ++j) {
+ /* a burst of 9 attempts must succeed */
+ for (i = 0; i < 9; ++i)
+ ck_assert(ratelimit_test(&rl) == RATELIMIT_PASS);
+
+ /* the 10th attempt reaches the threshold */
+ ck_assert(ratelimit_test(&rl) == RATELIMIT_THRESHOLD);
+
+ /* ..then further attempts must fail.. */
+ ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
+
+ /* ..regardless of how often we try. */
+ for (i = 0; i < 100; ++i)
+ ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
+
+ /* ..even after waiting 5ms */
+ msleep(5);
+ for (i = 0; i < 100; ++i)
+ ck_assert(ratelimit_test(&rl) == RATELIMIT_EXCEEDED);
+
+ /* but after 10ms the counter is reset */
+ msleep(6); /* +1ms to account for time drifts */
+ }
+}
+END_TEST
+
int main (int argc, char **argv) {
litest_add_no_device("events:conversion",
event_conversion_device_notify);
litest_add_no_device("events:conversion", event_conversion_pointer);
@@ -519,5 +553,7 @@ int main (int argc, char **argv) {
litest_add_no_device("config:status string", config_status_string);
litest_add_no_device("misc:matrix", matrix_helpers);
+ litest_add_no_device("misc:ratelimit", ratelimit_helpers);
+
return litest_run(argc, argv);
}
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/2] util: introduce ratelimit helpers
Hi
On Wed, Nov 5, 2014 at 6:11 AM, Peter Hutterer wrote:
> On Tue, Nov 04, 2014 at 09:35:37AM +0100, David Herrmann wrote:
>> This adds "struct ratelimit" and "ratelimit_test()". It's a very simple
>> rate-limit helper modeled after Linux' lib/ratelimit.c by Dave Young.
>>
>> This comes in handy to limit log-messages in possible busy loops etc..
>>
>> Signed-off-by: David Herrmann
>> ---
>> src/libinput-util.c | 48
>> src/libinput-util.h | 19 +++
>> test/misc.c | 37 +
>> 3 files changed, 104 insertions(+)
>>
>> diff --git a/src/libinput-util.c b/src/libinput-util.c
>> index eeb9786..19594e3 100644
>> --- a/src/libinput-util.c
>> +++ b/src/libinput-util.c
>> @@ -65,3 +65,51 @@ list_empty(const struct list *list)
>> {
>> return list->next == list;
>> }
>> +
>> +/*
>> + * Perform rate-limit test. Returns true if the rate-limited action is still
>> + * allowed, false if it should be suppressed.
>> + *
>> + * The ratelimit object must be initialized via RATELIMIT_INIT().
>> + *
>> + * Modelled after Linux' lib/ratelimit.c by Dave Young
>> + * , which is licensed GPLv2.
>> + */
>> +bool ratelimit_test(struct ratelimit *r)
>
> libinput style is: return type on a separate line
Fixed.
>> +{
>> + struct timespec ts;
>> + uint64_t utime;
>> +
>> + if (r->interval <= 0 || r->burst <= 0)
>> + return true;
>> +
>> + clock_gettime(CLOCK_MONOTONIC, &ts);
>> + utime = ts.tv_sec * 1000 * 1000 + ts.tv_nsec / 1000;
>> +
>> + if (r->begin <= 0 || r->begin + r->interval < utime) {
>> + /* reset counter */
>> + r->begin = utime;
>> + r->num = 1;
>> + return true;
>> + } else if (r->num < r->burst) {
>> + /* continue burst */
>> + r->num++;
>> + return true;
>> + }
>> +
>> + /* rate-limit with overflow check */
>> + if (r->num + 1 > r->num)
>> + ++r->num;
>> +
>> + return false;
>> +}
>> +
>> +/*
>> + * Return true if the ratelimit counter just crossed the cutoff value. That
>> is,
>> + * this function returns true iff the last call to ratelimit_test() was the
>
> s/iff/if/
"Iff" is widely used for "if, and only if," [1]. Should I still change it?
>> + * first call to exceed the burst value in this interval.
>> + */
>> +bool ratelimit_cutoff(struct ratelimit *r)
>
> bool on separate line please
Fixed.
>> +{
>> + return r->num == r->burst + 1;
>> +}
>
>
> I'm wondering: why have two separate functions here?
>
> how about an
> enum ratelimit {
> RATELIMIT_PASS,
> RATELIMIT_THRESHOLD,
> RATELIMIT_EXCEEDED,
> };
>
> then return that from ratelimit_test and then use the return value to
> decide on the rest of the handling?
> so the dispatch code would be:
> if ((rc = ratelimit_test(...)) != RATELIMIT_EXCEEDED)) {
> log_info("SYN_DROPPED");
> if (rc == RATELIMIT_THRESHOLD) {
> log_info("SYN_DROPPED flood");
> }
> }
>
> or the same with a switch statement.
Sure, can do that.
>> diff --git a/src/libinput-util.h b/src/libinput-util.h
>> index 51759e8..8ff8778 100644
>> --- a/src/libinput-util.h
>> +++ b/src/libinput-util.h
>> @@ -25,6 +25,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -280,4 +281,22 @@ matrix_to_farray6(const struct matrix *m, float out[6])
>> out[5] = m->val[1][2];
>> }
>>
>> +struct ratelimit {
>> + uint64_t interval;
>> + uint64_t begin;
>> + unsigned burst;
>> + unsigned num;
>
> unsigned int please
Fixed.
>> +} RateLimit;
>
> well, hello. what are you doing here? are you lost? :)
Weird.. gcc didn't warn me about this unused variable.. Fixed.
>> +
>> +#define RATELIMIT_INIT(_interval, _burst)\
>> + ((struct ratelimit){\
>> + .interval = (_interval),\
>> + .begin = 0, \
>> + .burst = (_burst), \
>> + .num = 0,
Re: [PATCH libinput v2] evdev: Log evdev event queue overflows
Hi
On Tue, Nov 4, 2014 at 12:17 AM, Peter Hutterer
wrote:
> On Mon, Nov 03, 2014 at 11:49:12AM +0100, David Herrmann wrote:
>> Hi
>>
>> On Wed, Oct 29, 2014 at 3:56 PM, Derek Foreman
>> wrote:
>> > Log a message when the kernel event queue overflows and events are dropped.
>> > After 10 messages logging stops to avoid flooding the logs if the condition
>> > is persistent.
>> > ---
>> > src/evdev.c | 11 +++
>> > src/evdev.h | 4
>> > 2 files changed, 15 insertions(+)
>> >
>> > diff --git a/src/evdev.c b/src/evdev.c
>> > index 1b4ce10..9026f5c 100644
>> > --- a/src/evdev.c
>> > +++ b/src/evdev.c
>> > @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data)
>> > rc = libevdev_next_event(device->evdev,
>> > LIBEVDEV_READ_FLAG_NORMAL, &ev);
>> > if (rc == LIBEVDEV_READ_STATUS_SYNC) {
>> > + if (device->syn_drops_received < 10) {
>> > + device->syn_drops_received++;
>> > + log_info(libinput, "SYN_DROPPED event from
>> > "
>> > +"\"%s\" - some input events have "
>> > +"been lost.\n", device->devname);
>> > + if (device->syn_drops_received == 10)
>> > + log_info(libinput, "No longer
>> > logging "
>> > +"SYN_DROPPED events for "
>> > +"\"%s\"\n",
>> > device->devname);
>> > + }
>> > +
>>
>> I really appreciate those log-messages, but can we use rate-limiting
>> here, rather than a per-device counter? I mean, my compositor usually
>> runs for multiple days, or even weeks. I really don't want it to stop
>> reporting SYN_DROPPED events just because it got 100 of those during
>> startup (or something similar).
>>
>> Something like this:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/ratelimit.c
>>
>> I can prep a patch if you want.
>
> good idea, let's do that.
I sent 2 patches to wayland-devel.
Thanks
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice
Hi On Tue, Nov 4, 2014 at 4:51 AM, Peter Hutterer wrote: > On Mon, Nov 03, 2014 at 11:56:59AM +0100, David Herrmann wrote: >> I haven't spent much time thinking it through, but so far I'd prefer a >> solid, but basic, heuristic to guess the DPI and then use hwdb for >> anything that doesn't fit. This allows us to change the heuristic at >> any time and we don't have to introduce any APIs. We can even ship the >> hwdb files with libinput. > > tbh, I don't think heuristics will work. there is no reference point and > when you're looking at relative motion you can't tell if a delta of > 10 means the pointer has moved a large distance at low-res or a small > distance at high-res. I was more talking about the MIN/MAX values reported by the device. I assumed that high-dpi devices just reported higher precision for the same interval as low-dpi devices. But as your data shows, this turns out to be not true... what a bummer! > Anyway, for some data: > I recorded my Logitech G500s here with three different dpi settings (400, > 800, 2000) and a MS Comfort Optical Mouse 3000 (1000 dpi). A couple of > interesting things: regardless of dpi, virtually all events are within [-3, > +3] dx/dy and there's nothing over 10. Exception here is the MS mouse which > goes up to 78 for a delta, for reasons I can't explain yet. Interesting. This is probably to throttle HID throughput and use report-on-change, instead of continuous-reporting. Anyway, if you want, I can come up with a hwdb format to retrieve DPI settings. Just lemme know what you want to match on for the devices. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/2] evdev: ratelimit SYN_DROPPED logging
Use the ratelimit helpers for SYN_DROPPED logging. This guarantees that we
will still receive SYN_DROPPED log-messages after multiple days of
runtime, even though there might have been a SYN_DROPPED flood at one
point in time.
Signed-off-by: David Herrmann
---
src/evdev.c | 14 +++---
src/evdev.h | 4 +---
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 3aa87a7..836ce56 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -926,16 +926,14 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device->evdev,
LIBEVDEV_READ_FLAG_NORMAL, &ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
- if (device->syn_drops_received < 10) {
- device->syn_drops_received++;
+ if (ratelimit_test(&device->syn_drop_limit))
log_info(libinput, "SYN_DROPPED event from "
"\"%s\" - some input events have "
"been lost.\n", device->devname);
- if (device->syn_drops_received == 10)
- log_info(libinput, "No longer logging "
-"SYN_DROPPED events for "
-"\"%s\"\n", device->devname);
- }
+ else if (ratelimit_cutoff(&device->syn_drop_limit))
+ log_info(libinput, "SYN_DROPPED flood "
+"for \"%s\"\n",
+device->devname);
/* send one more sync event so we handle all
currently pending events before we sync up
@@ -1296,6 +1294,8 @@ evdev_device_create(struct libinput_seat *seat,
device->scroll.threshold = 5.0; /* Default may be overridden */
device->scroll.direction = 0;
device->dpi = DEFAULT_MOUSE_DPI;
+ /* at most 5 SYN_DROPPED log-messages per 30s */
+ device->syn_drop_limit = RATELIMIT_INIT(30ULL * 1000 * 1000, 5);
matrix_init_identity(&device->abs.calibration);
matrix_init_identity(&device->abs.usermatrix);
diff --git a/src/evdev.h b/src/evdev.h
index 666c8dc..eefbb79 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -137,9 +137,7 @@ struct evdev_device {
} buttons;
int dpi; /* HW resolution */
- /* The number of times libevdev processes a SYN_DROPPED, so we can
-* stop logging them to avoid flooding the logs. */
- int syn_drops_received;
+ struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
};
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
--
2.1.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/2] util: introduce ratelimit helpers
This adds "struct ratelimit" and "ratelimit_test()". It's a very simple
rate-limit helper modeled after Linux' lib/ratelimit.c by Dave Young.
This comes in handy to limit log-messages in possible busy loops etc..
Signed-off-by: David Herrmann
---
src/libinput-util.c | 48
src/libinput-util.h | 19 +++
test/misc.c | 37 +
3 files changed, 104 insertions(+)
diff --git a/src/libinput-util.c b/src/libinput-util.c
index eeb9786..19594e3 100644
--- a/src/libinput-util.c
+++ b/src/libinput-util.c
@@ -65,3 +65,51 @@ list_empty(const struct list *list)
{
return list->next == list;
}
+
+/*
+ * Perform rate-limit test. Returns true if the rate-limited action is still
+ * allowed, false if it should be suppressed.
+ *
+ * The ratelimit object must be initialized via RATELIMIT_INIT().
+ *
+ * Modelled after Linux' lib/ratelimit.c by Dave Young
+ * , which is licensed GPLv2.
+ */
+bool ratelimit_test(struct ratelimit *r)
+{
+ struct timespec ts;
+ uint64_t utime;
+
+ if (r->interval <= 0 || r->burst <= 0)
+ return true;
+
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+ utime = ts.tv_sec * 1000 * 1000 + ts.tv_nsec / 1000;
+
+ if (r->begin <= 0 || r->begin + r->interval < utime) {
+ /* reset counter */
+ r->begin = utime;
+ r->num = 1;
+ return true;
+ } else if (r->num < r->burst) {
+ /* continue burst */
+ r->num++;
+ return true;
+ }
+
+ /* rate-limit with overflow check */
+ if (r->num + 1 > r->num)
+ ++r->num;
+
+ return false;
+}
+
+/*
+ * Return true if the ratelimit counter just crossed the cutoff value. That is,
+ * this function returns true iff the last call to ratelimit_test() was the
+ * first call to exceed the burst value in this interval.
+ */
+bool ratelimit_cutoff(struct ratelimit *r)
+{
+ return r->num == r->burst + 1;
+}
diff --git a/src/libinput-util.h b/src/libinput-util.h
index 51759e8..8ff8778 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -280,4 +281,22 @@ matrix_to_farray6(const struct matrix *m, float out[6])
out[5] = m->val[1][2];
}
+struct ratelimit {
+ uint64_t interval;
+ uint64_t begin;
+ unsigned burst;
+ unsigned num;
+} RateLimit;
+
+#define RATELIMIT_INIT(_interval, _burst) \
+ ((struct ratelimit){\
+ .interval = (_interval),\
+ .begin = 0, \
+ .burst = (_burst), \
+ .num = 0, \
+ })
+
+bool ratelimit_test(struct ratelimit *r);
+bool ratelimit_cutoff(struct ratelimit *r);
+
#endif /* LIBINPUT_UTIL_H */
diff --git a/test/misc.c b/test/misc.c
index 1512180..70b3e57 100644
--- a/test/misc.c
+++ b/test/misc.c
@@ -508,6 +508,42 @@ START_TEST(matrix_helpers)
}
END_TEST
+START_TEST(ratelimit_helpers)
+{
+ /* 10 attempts every 10ms */
+ struct ratelimit rl = RATELIMIT_INIT(1, 10);
+ unsigned int i, j;
+
+ for (j = 0; j < 100; ++j) {
+ /* a burst of 10 attempts must succeed */
+ for (i = 0; i < 10; ++i) {
+ ck_assert(ratelimit_test(&rl));
+ ck_assert(!ratelimit_cutoff(&rl));
+ }
+
+ /* ..then further attempts must fail.. */
+ ck_assert(!ratelimit_test(&rl));
+ ck_assert(ratelimit_cutoff(&rl));
+
+ /* ..regardless of how often we try. */
+ for (i = 0; i < 100; ++i) {
+ ck_assert(!ratelimit_test(&rl));
+ ck_assert(!ratelimit_cutoff(&rl));
+ }
+
+ /* ..even after waiting 5ms */
+ usleep(5000);
+ for (i = 0; i < 100; ++i) {
+ ck_assert(!ratelimit_test(&rl));
+ ck_assert(!ratelimit_cutoff(&rl));
+ }
+
+ /* but after 10ms the counter is reset */
+ usleep(6000); /* +1ms to account for time drifts */
+ }
+}
+END_TEST
+
int main (int argc, char **argv) {
litest_add_no_device("events:conversion",
event_conversion_device_notify);
litest_add_no_device("events:conversion", event_conversion_pointer);
@@ -519,5 +555,6 @@ int main (int argc, char **argv) {
litest_add_no_device("config:status string", config_status_string);
litest_add_no_device("misc:matrix", matrix_helpers);
+
Re: [PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice
Hi On Fri, Oct 31, 2014 at 5:33 AM, Peter Hutterer wrote: > On Thu, Oct 30, 2014 at 04:34:12PM -0500, Derek Foreman wrote: >> The acceleration filter currently isn't particularly pleased with gaming >> mice. >> >> They generally have high DPI (can be over 8000 DPI) and can have high update >> rates (1000+ per second). This can result in the accel curve being biased >> heavily towards the high points on the accel curve. >> >> This patch set allows a way to normalize the deltas to 400DPI so when the >> DPI setting of the mouse is correct, it should feel much the same as a >> normal mouse. >> >> This is, of course, only a partial solution. Setting a reasonable default >> is a massive problem that needs to be addressed in the future - for now >> we just set it to 400 (which may actually not be that prevalent any more >> but there doesn't seem to be such thing as a "standard" DPI mouse). > > Thanks, I've pushed 1 to 3 (with added comments), not quite happy with > 4 yet. As a configuration interface, it's mismatched with the usual quartett > of hooks that we provide for all other config options. > > But I think providing a visible API may not be the right approach here > anyway. One idea I had here was to have this provided through udev, set > as something like: > LIBINPUT_MOUSE_DPI="400@80" # dpi @ poll rate > > over time, the udev hwdb could add those settings, or we ship them as > extra rules, or users configure them themselves. this is unfortunately a > rather nasty task given the amount of HW out there, but I really can't think > of any other way (short of heuristics which will fail in too many ways). > > Any ideas on feasability or better approaches welcome. hwdb can be used easily here, but it's indeed a huge amount to gather all that data. HID doesn't have a way to query this information, sadly, and I haven't found any generic vendor extensions (maybe Benjamin knows more). We could use the REL_X/REL_Y MAX values to guess the DPI setting and ignore it if it's out of the expected range (sth. like 100-10k). I haven't spent much time thinking it through, but so far I'd prefer a solid, but basic, heuristic to guess the DPI and then use hwdb for anything that doesn't fit. This allows us to change the heuristic at any time and we don't have to introduce any APIs. We can even ship the hwdb files with libinput. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v2] evdev: Log evdev event queue overflows
Hi
On Wed, Oct 29, 2014 at 3:56 PM, Derek Foreman wrote:
> Log a message when the kernel event queue overflows and events are dropped.
> After 10 messages logging stops to avoid flooding the logs if the condition
> is persistent.
> ---
> src/evdev.c | 11 +++
> src/evdev.h | 4
> 2 files changed, 15 insertions(+)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 1b4ce10..9026f5c 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data)
> rc = libevdev_next_event(device->evdev,
> LIBEVDEV_READ_FLAG_NORMAL, &ev);
> if (rc == LIBEVDEV_READ_STATUS_SYNC) {
> + if (device->syn_drops_received < 10) {
> + device->syn_drops_received++;
> + log_info(libinput, "SYN_DROPPED event from "
> +"\"%s\" - some input events have "
> +"been lost.\n", device->devname);
> + if (device->syn_drops_received == 10)
> + log_info(libinput, "No longer logging
> "
> +"SYN_DROPPED events for "
> +"\"%s\"\n", device->devname);
> + }
> +
I really appreciate those log-messages, but can we use rate-limiting
here, rather than a per-device counter? I mean, my compositor usually
runs for multiple days, or even weeks. I really don't want it to stop
reporting SYN_DROPPED events just because it got 100 of those during
startup (or something similar).
Something like this:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/ratelimit.c
I can prep a patch if you want.
Thanks
David
> /* send one more sync event so we handle all
>currently pending events before we sync up
>to the current state */
> diff --git a/src/evdev.h b/src/evdev.h
> index c0d6577..9e84623 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -135,6 +135,10 @@ struct evdev_device {
> /* Checks if buttons are down and commits the setting */
> void (*change_to_left_handed)(struct evdev_device *device);
> } buttons;
> +
> + /* The number of times libevdev processes a SYN_DROPPED, so we can
> +* stop logging them to avoid flooding the logs. */
> + int syn_drops_received;
> };
>
> #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
> --
> 2.1.1
>
> ___
> 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 libxkbcommon 2/4] compose: add xkbcommon-compose - implementation
Hi On Mon, Sep 15, 2014 at 1:58 PM, Ran Benita wrote: > On Mon, Sep 15, 2014 at 08:21:34AM +0200, David Herrmann wrote: >> Why don't we require a keymap in xkb_compose_state_new()? Should be >> easy to do and we can then track modifiers reliably. >> Ok, a keysym which is a modifier in one keymap should never be a >> normal key in another.. unlike keycodes. But I don't see why we need >> to rely on that when we can just take a keymap. > > I prefer not adding a dependency on a keymap just for this one little > thing. That would preclude people who don't use xkbcommon keymaps from > using xkbcommon-compose (not likely, but maybe), and complicate the API > slightly. For not much gain.. We could allow NULL and then use this fallback.. > Also, that's what the de facto specification here (Xlib) says, so it's not > a bug, it's a feature :) Fair enough. You might guess that I don't care much about Xlib, but this is just a nitpick so I'm fine either way. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libxkbcommon 1/4] compose: add xkbcommon-compose - API
Hi
On Mon, Sep 15, 2014 at 1:48 PM, Ran Benita wrote:
> On Mon, Sep 15, 2014 at 08:41:37AM +0200, David Herrmann wrote:
>> Hi
>
> Hi David
>
>> On Sun, Sep 14, 2014 at 11:05 PM, Ran Benita wrote:
> [snip]
>> > +/**
>> > + * @page compose-cancellation Cancellation Behavior
>> > + * @parblock
>> > + *
>> > + * What should happen when a sequence is cancelled? For example, consider
>> > + * there are only the above sequences, and the input kesysms are
>> > + * \ \. There are a few approaches:
>> > + *
>> > + * 1. Swallow the cancelling keysym; that is, no keysym is produced.
>> > + *This is the approach taken by libX11.
>> > + * 2. Let the cancelling keysym through; that is, \ is produced.
>> > + * 3. Replay the entire sequence; that is, \ \ is
>> > produced.
>> > + *This is the approach taken by Microsoft Windows (approximately;
>> > + *instead of \, the underlying key is used. This is
>> > + *difficult to simulate with XKB keymaps).
>> > + *
>> > + * You can program whichever approach best fits users' expectations.
>>
>> Hm, implementing 3) is a pain as we have to track the keysyms
>> separately. Your compose-API does not provide a way to retrieve the
>> parsed/failed sequence.
>
> I think alternative 3 is the nicest really, so I want to make it
> possible, without too much work if possible.
I agree!
> Tracking the sequence is possible - I've added a return value to
> xkb_compose_state_feed() for this purpose. It can be done with e.g. a
> wrapper over xkb_compose_state_feed(), something like:
Yes, sure, but I wanted to avoid tracking it separately. We could just
climb up the compose-trie after we cancelled it and recreate the list
of keysyms?
If that's not possible, tracking it separately should be fine. It
isn't that much work..
>> But given that we have no dead-key =>
>> normal-key conversion right now, it's probably fine. If we want it, we
>> can add an API for both later on (assuming a trivial keysym conversion
>> from dead_key => normal is possible).
>
> Yes, maybe we can add such a function, once we have more experience.
> Another option, which relies entirely on convention, is to feed the
> dead key twice, and see what comes out:
>
> $ grep -P '^ '
> /usr/share/X11/locale/en_US.UTF-8/Compose
>
> : "~" asciitilde # TILDE
> : "´" acute # ACUTE ACCENT
> : "`" grave # GRAVE ACCENT
> : "^" asciicircum # CIRCUMFLEX
> ACCENT
> : "°" degree # DEGREE SIGN
> : "¯" macron # MACRON
> : "˘" breve # BREVE
> : "˙" abovedot # DOT ABOVE
> : "¨" diaeresis # DIAERESIS
> : "˝" U2dd # DOUBLE ACUTE ACCENT
> : "ˇ" caron # CARON
> : "¸" cedilla # CEDILLA
> : "˛" ogonek # OGONEK
> : "ͺ" U37a # GREEK YPOGEGRAMMENI
> : "̣" U0323 # COMBINING DOT
> BELOW
> : "," comma # COMMA
> : "¤" currency # CURRENCY SIGN
> : "µ" U00B5 # MICRO SIGN
> : "̉" U0309 # COMBINING HOOK
> ABOVE
> : "̛" U031B # COMBINING HORN
> : "/" slash # SOLIDUS
>
> Probably not a good idea..
Ewww!
>> > +/** Status of the Compose sequence state machine. */
>> > +enum xkb_compose_status {
>> > +/** The initial state; no sequence has started yet. */
>> > +XKB_COMPOSE_NOTHING,
>> > +/** In the middle of a sequence. */
>> > +XKB_COMPOSE_COMPOSING,
>> > +/** A complete sequence has been matched. */
>> > +XKB_COMPOSE_COMPOSED,
>> > +/** The last sequence was cancelled due to an invalid keysym. */
>> > +XKB_COMPOSE_CANCELLED
>>
>> It is unclear what happens if a keysym is pressed that is _not_ part
>> of a compose sequence (that is, most keys). 'context' is 0 but no
>> matching compose node is found. I assume it generates
>> XKB_COMPOSE_NOTHING, but the comment here is unclear. Maybe the
>> _feed() or _get_state() description should mention how keys are
>> treated that are not part of compose sequences (and which are fed
>> while no compose sequence is active). I assume we do *not* return
>
Re: Weston and multiseat
Hi On Mon, Sep 15, 2014 at 8:38 AM, Daniel J Blueman wrote: > Has anyone met success using Wayland (or any other compositors) > multi-seat with a single GPU (Intel in my case), eg booting linux-3.16 > with drm.rnodes=1? You cannot do this. DRM cards do not allow splitting modeset resources across masters (so far). There have been ideas how we could implement this, but no-one sent patches, yet. For now, you need to have multiple GPUs to run multiple seats. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libxkbcommon 1/4] compose: add xkbcommon-compose - API
Hi
On Sun, Sep 14, 2014 at 11:05 PM, Ran Benita wrote:
> xkbcommon-compose is a Compose implementation for xkbcommon. It mostly
> behaves like libX11's Compose, but the support is somewhat low-level and
> is not transparent like in libX11. The user must add some supporting code
> in order to utilize it.
>
> The intended audience are users who use xkbcommon but not a full-blown
> input method. With this they can add Compose support in a straightforward
> manner, so they have a fairly complete keyboard input for Latin-like
> languages at least.
>
> See the header documentation for details.
>
> Signed-off-by: Ran Benita
> ---
> xkbcommon/xkbcommon-compose.h | 457
> ++
> 1 file changed, 457 insertions(+)
> create mode 100644 xkbcommon/xkbcommon-compose.h
>
> diff --git a/xkbcommon/xkbcommon-compose.h b/xkbcommon/xkbcommon-compose.h
> new file mode 100644
> index 000..ed35250
> --- /dev/null
> +++ b/xkbcommon/xkbcommon-compose.h
> @@ -0,0 +1,457 @@
> +/*
> + * Copyright © 2013 Ran Benita
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XKBCOMMON_COMPOSE_H
> +#define _XKBCOMMON_COMPOSE_H
> +
> +#include
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * @file
> + * libxkbcommon Compose API - support for Compose and dead-keys.
> + */
> +
> +/**
> + * @defgroup compose Compose and dead-keys support
> + * Support for Compose and dead-keys.
> + * @since TBD
> + *
> + * @{
> + */
> +
> +/**
> + * @page compose-overview Overview
> + * @parblock
> + *
> + * Compose and dead-keys are a common feature of many keyboard input
> + * systems. They extend the range of the keysysm that can be produced
> + * directly from a keyboard by using a sequence of key strokes, instead
> + * of just one.
> + *
> + * Here are some example sequences, in the libX11 Compose file format:
> + *
> + * : "á" aacute # LATIN SMALL LETTER A WITH
> ACUTE
> + * : "@" at # COMMERCIAL AT
> + *
> + * When the user presses a key which produces the \ keysym,
> + * nothing initially happens (thus the key is dubbed a "dead-key"). But
> + * when the user enters , "á" is "composed", in place of "a". If
> + * instead the user had entered a keysym which does not follow
> + * \ in any compose sequence, the sequence is said to be
> + * "cancelled".
> + *
> + * Compose files define many such sequences. For a description of the
> + * common file format for Compose files, see the Compose(5) man page.
> + *
> + * A successfuly-composed sequence has two results: a keysym and a UTF-8
> + * string. At least one of the two is defined for each sequence. If only
> + * a keysym is given, the keysym's string representation is used for the
> + * result string (using xkb_keysym_to_utf8()).
> + *
> + * This library provides low-level support for Compose file parsing and
> + * processing. Higher-level APIs (such as libX11's Xutf8LookupString(3))
> + * may be built upon it, or it can be used directly.
> + *
> + * @endparblock
> + */
> +
> +/**
> + * @page compose-conflicting Conflicting Sequences
> + * @parblock
> + *
> + * To avoid ambiguity, a sequence is not allowed to be a prefix of another.
> + * In such a case, the conflict is resolved thus:
> + *
> + * 1. A longer sequence overrides a shorter one.
> + * 2. An equal sequence overrides an existing one.
> + * 3. A shorter sequence does not override a longer one.
> + *
> + * Sequences of length 1 are allowed, although they are not common.
> + *
> + * @endparblock
> + */
> +
> +/**
> + * @page compose-cancellation Cancellation Behavior
> + * @parblock
> + *
> + * What should happen when a sequence is cancelled? For example, consider
> + * there are only the above sequences, and the input kesysms are
> + * \ \. There are a few approaches:
> + *
> + * 1. Swallow the cancelling keysym; that is, no keysym
Re: [PATCH libxkbcommon 2/4] compose: add xkbcommon-compose - implementation
Hi
On Sun, Sep 14, 2014 at 11:05 PM, Ran Benita wrote:
> Signed-off-by: Ran Benita
> ---
[snip]
> diff --git a/src/compose/state.c b/src/compose/state.c
> new file mode 100644
> index 000..06e4ce5
> --- /dev/null
> +++ b/src/compose/state.c
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright © 2013 Ran Benita
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "table.h"
> +#include "utils.h"
> +#include "keysym.h"
> +
> +struct xkb_compose_state {
> +int refcnt;
> +enum xkb_compose_state_flags flags;
> +struct xkb_compose_table *table;
> +
> +/*
> + * Offsets into xkb_compose_table::nodes.
> + *
> + * They maintain the current and previous position in the trie; see
> + * xkb_compose_state_feed().
> + *
> + * This is also sufficient for inferring the current status; see
> + * xkb_compose_state_get_status().
> + */
> +uint32_t prev_context;
> +uint32_t context;
> +};
> +
> +XKB_EXPORT struct xkb_compose_state *
> +xkb_compose_state_new(struct xkb_compose_table *table,
> + enum xkb_compose_state_flags flags)
> +{
> +struct xkb_compose_state *state;
> +
> +state = calloc(1, sizeof(*state));
> +if (!state)
> +return NULL;
> +
> +state->refcnt = 1;
> +state->table = xkb_compose_table_ref(table);
> +
> +state->flags = flags;
> +state->prev_context = 0;
> +state->context = 0;
> +
> +return state;
> +}
> +
> +XKB_EXPORT struct xkb_compose_state *
> +xkb_compose_state_ref(struct xkb_compose_state *state)
> +{
> +state->refcnt++;
> +return state;
> +}
> +
> +XKB_EXPORT void
> +xkb_compose_state_unref(struct xkb_compose_state *state)
> +{
> +if (!state || --state->refcnt > 0)
> +return;
> +
> +xkb_compose_table_unref(state->table);
> +free(state);
> +}
> +
> +XKB_EXPORT struct xkb_compose_table *
> +xkb_compose_state_get_compose_table(struct xkb_compose_state *state)
> +{
> +return state->table;
> +}
> +
> +XKB_EXPORT enum xkb_compose_feed_result
> +xkb_compose_state_feed(struct xkb_compose_state *state, xkb_keysym_t keysym)
> +{
> +uint32_t context;
> +const struct compose_node *node;
> +
> +/*
> + * Modifiers do not affect the sequence directly. In particular,
> + * they do not cancel a sequence; otherwise it'd be impossible to
> + * have a sequence like (needs Shift in the middle).
> + *
> + * The following test is not really accurate - in order to test if
> + * a key is "modifier key", we really need the keymap, but we don't
> + * have it here. However, this is (approximately) what libX11 does
> + * as well.
> + */
> +if (xkb_keysym_is_modifier(keysym))
> +return XKB_COMPOSE_FEED_IGNORED;
Why don't we require a keymap in xkb_compose_state_new()? Should be
easy to do and we can then track modifiers reliably.
Ok, a keysym which is a modifier in one keymap should never be a
normal key in another.. unlike keycodes. But I don't see why we need
to rely on that when we can just take a keymap.
Otherwise, looks good (I didn't read through the parser, though).
Thanks
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Wrong bo handles can be referenced in func call, drmModeAddFB2 due to uninitialized array elements in handles[4]
Hi On Tue, Apr 29, 2014 at 10:59 PM, Matt Roper wrote: > On Tue, Apr 29, 2014 at 01:24:31PM -0700, Kristian Høgsberg wrote: >> On Mon, Apr 28, 2014 at 03:26:18PM -0700, Dongwon Kim wrote: >> > Need all bo handles in the array, handles[4] to be initialized with >> > integer value that >> > indicates "NOT VALID handle" to prevent any of those uninitialized from >> > being processed as >> > "VALID" handles. >> >> The format code determines which bo handles are used. For non-planar formats >> only the first handle is used and the rest can be uninitialized. >> >> Kristian > > Some hardware allows/expects stereo 3D to be supported by programming > the hardware with separate buffers for the left eye and right eye > content. Drivers for such hardware need both handles[0] and handles[1] > to pass the left and right content buffers that get wrapped into a > single DRM fb, even though the pixel format is just RGB. At the time > AddFB2 gets called, you don't know yet whether it's going to get > displayed on a stereo mode or a mono mode, so if there's something > sitting in handles[1], the driver will try to look it up. You cannot break backwards-compat this way. A lot of user-space assumes that only handles[0] is used. Afaik, the kernel has a 3d-stereo user-capability, so unless it is set, you shouldn't do that in the kernel. However, given that weston might set this flag at some point, the patch is still right. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ANNOUNCE] libxkbcommon-0.4.1
Hi
On Thu, Mar 27, 2014 at 11:41 PM, Ran Benita wrote:
> Regarding intended use-case for multiple-keysyms, I consider it mainly
> to be for sequences with combining characters - not everything has
> precomposed codepoints, so if you want one of these, you don't have a
> way to do it with single-keysym, but it still conceptually fits in a
> keymap. However for the original intent you have to ask Daniel.
Ok, so should be handled as atomic key-press.
> Sure, the old functions are still useful for getting the "raw"
> translation if you want it. And you're right about the docs - I'll add
> some hopefully-not-too-confusing details instead of just "prefer the new
> ones". Full details are in the bugs and commit msgs but of course I
> don't expect anyone to read that :)
Yeah, commit-message is great for xkbcommon developers, not so much
for new API users. Thanks!
>> Btw., same is true for the implicit caps-lock magic in
>> xkb_state_key_get_one_sym(). I'm now quite confused whether
>> xkb_state_key_get_syms() users have to do caps-lock handling
>> explicitly? Or is that done by keymaps?
>
> Currently to get the implicit capitalization with get_syms(), you have
> to do this:
>
> int nsyms;
> const xkb_keysym_t *syms;
> xkb_keysym_t sym;
>
> nsyms = xkb_state_key_get_syms(..., &syms);
> if (nsyms == 1) {
> sym = xkb_state_key_get_one_sym(...);
> syms = &sym;
> }
>
> I imagine the disgust, but given the set of constraints we had I
> couldn't think of any way to make this work. New API is still possible,
> but then we'd have *three* ways to get keysyms...
>
> As I may have mentioned, I wanted to change the *keymaps* so the
> difference doesn't matter here. I still plan to send some patches for
> easy cases, but fixing other cases would require major xkeyboard-config
> surgery. So we're stuck with it.
That somehow gives me the impression capslock is currently not handled
by keymaps? Oh, didn't even notice that. Sounds like a gross hack. But
yes, fixing all keymaps sounds like rather cumbersome work given that
there's no real gain in it.
Thanks
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ANNOUNCE] libxkbcommon-0.4.1
Hi
On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita wrote:
> - Added two new functions, xkb_state_key_get_utf{8,32}(). They
> combine the operations of xkb_state_key_get_syms() and
> xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
> (espcially for multiple-keysyms-per-level).
Slightly off-topic, but looking at the code, you ignore any multi-sym
values (nsyms != 1). Users of that API might rely on that behavior, so
have we at some point defined what exactly multi-sym means? Because if
we add more and more APIs and if the user-base grows, we might at some
point be unable to make use of multi-symbol behavior. I'm still not
sure whether nsyms > 1 just means multiple sequential keysyms, or
whether they should be handled as _one_ atomic combined keysym?
> - The xkb_state_key_get_utf{8,32}() functions now apply Control
> transformation: when the Control modifier is active, the string
> is converted to an appropriate control character.
> This matches the behavior of libX11's XLookupString(3), and
> required by the XKB specification:
>
> http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier
>
> https://bugs.freedesktop.org/show_bug.cgi?id=75892
So xkb_state_key_get_utf8(state, code) !=
xkb_keysym_to_utf8(xkb_state_key_get_one_sym(state, code))? (at least
for ctrl+)
Could we at least add a note/warning to the documentation? I cannot
find anything here:
http://xkbcommon.org/doc/current/group__state.html#ga0774b424063b45c88ec0354c77f9a247
For instance, for libtsm, I accept combined modifier+keysym+ucs4string
input from the GUI layer and transform that internally. If the upper
layer uses xkb_state_key_get_utf32() instead of xkb_keysym_to_utf32(),
the logic will force the control-seq even though it might be mapped
differently by the vte-layer (for instance, there's stuff like
shifting values by 64 if ALT is pressed, and more legacy crap we need
to support for eternity). Sure, most libtsm code uses the keysym, but
for glyph transformation we have to use the ucs4 value. Imagine the
ctrl+c input was shifted by the term-layer, you still end up with the
\003 glyph, because the ucs4 string was mapped by xkbcommon.
I'm not saying the patch is wrong, in fact, the layout-search logic is
actually what you wrote for kmscon and I appreciate that. I'm just
saying that it's a really subtle API difference that can introduce
weird bugs. Lets see how it works out, but if people start using
xkb_state_key_get_utf32(), I might send a patch adding an xkb-state
flag that disables this transformation. Or just force users to not use
it (which would be unfortunate).
Btw., same is true for the implicit caps-lock magic in
xkb_state_key_get_one_sym(). I'm now quite confused whether
xkb_state_key_get_syms() users have to do caps-lock handling
explicitly? Or is that done by keymaps?
Anyhow, thanks for the release!
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How synchronisation works in Framebuffer backend
Hi On Sat, Mar 22, 2014 at 6:33 PM, Sannu K wrote: > Hi, > > I was going through weston's framebuffer backend code. It does not call > FBIO_WAITFORVSYNC ioctl. > http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-fbdev.c#n188 > says that it is not used intentionally. In this case, how weston syncs frame > with the framebuffer clock? How tearing is avoided? > > Thanks in advance for the help. It doesn't. Don't use fbdev if you want vsync. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH libinput] udev: add libinput_udev_rescan_devices()
Hi On Fri, Mar 21, 2014 at 6:14 AM, Peter Hutterer wrote: > On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote: >> So you're saying that every time we're suspended, we simply throw out the >> entire context and drop all the devices on the floor, as if you just >> unplugged all of them? > > fwiw, this is effectively what happens internally anyway, you get removed > events for every device on suspend, and added events on resume for those > still there. > >> I suppose I just never thought of that. On first though, I don't see >> anything wrong with that. >> >> If that's what we should do, should we remove libinput_suspend / >> libinput_resume then? > > libinput_suspend/resume only tear down the devices, but not anything > else. there isn't much global state that's kept across suspend/resume yet > (seats are one example though) but the biggest difference is that that you > can't use _any_ object around after libinput_destroy(). suspend/resume > keeps them alive until you unref them. Just to verify the assumptions: Yes, the kernel throws away the whole context, but in user-space you can try to keep your devices around and just resync them on resume. At least that's what I did. And use the real udev-events to decide when the device has really gone away. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] weston-launch: Let the user use her real shell
Hi
On Fri, Jan 24, 2014 at 7:13 AM, Quentin Glidic
wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> src/weston-launch.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/weston-launch.c b/src/weston-launch.c
> index 56e22b1..fd04552 100644
> --- a/src/weston-launch.c
> +++ b/src/weston-launch.c
> @@ -103,6 +103,7 @@ struct weston_launch {
>
> pid_t child;
> int verbose;
> + int user_shell;
> char *new_user;
> };
>
> @@ -644,7 +645,7 @@ launch_compositor(struct weston_launch *wl, int argc,
> char *argv[])
> sigaddset(&mask, SIGINT);
> sigprocmask(SIG_UNBLOCK, &mask, NULL);
>
> - child_argv[0] = "/bin/sh";
> + child_argv[0] = wl->user_shell ? wl->pw->pw_shell : "/bin/sh";
weston-launch passes privileged FDs back to weston. I don't think we
should allow a user to use their own shell to spawn weston. How can
you guarantee the shell does not point to some random binary of the
user? This way, they can get access to arbitrary input FDs,
circumventing the access-mode restrictions on the device-nodes.
Thanks
David
> child_argv[1] = "-l";
> child_argv[2] = "-c";
> child_argv[3] = BINDIR "/weston \"$@\"";
> @@ -663,6 +664,7 @@ help(const char *name)
> fprintf(stderr, "Usage: %s [args...] [-- [weston args..]]\n", name);
> fprintf(stderr, " -u, --user Start session as specified
> username\n");
> fprintf(stderr, " -t, --tty Start session on alternative
> tty\n");
> + fprintf(stderr, " -s, --shell Use the user shell instead of
> /bin/sh to run weston\n");
> fprintf(stderr, " -v, --verbose Be verbose\n");
> fprintf(stderr, " -h, --help Display this help message\n");
> }
> @@ -676,6 +678,7 @@ main(int argc, char *argv[])
> struct option opts[] = {
> { "user",required_argument, NULL, 'u' },
> { "tty", required_argument, NULL, 't' },
> + { "shell", no_argument, NULL, 's' },
> { "verbose", no_argument, NULL, 'v' },
> { "help",no_argument, NULL, 'h' },
> { 0, 0, NULL, 0 }
> @@ -683,7 +686,7 @@ main(int argc, char *argv[])
>
> memset(&wl, 0, sizeof wl);
>
> - while ((c = getopt_long(argc, argv, "u:t::vh", opts, &i)) != -1) {
> + while ((c = getopt_long(argc, argv, "u:t::svh", opts, &i)) != -1) {
> switch (c) {
> case 'u':
> wl.new_user = optarg;
> @@ -693,6 +696,9 @@ main(int argc, char *argv[])
> case 't':
> tty = optarg;
> break;
> + case 's':
> + wl.user_shell = 1;
> + break;
> case 'v':
> wl.verbose = 1;
> break;
> --
> 1.8.5.3
>
> ___
> 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: Announcing Termistor, a drop-down, tabbed, terminal for Wayland
Hi On Thu, Dec 26, 2013 at 10:47 PM, Giulio Camuffo wrote: > Hi all, > > I've finally found a way to squeeze good performances out of my > terminal embryo I've had for a few months, so I hereby announce the > birth of the first drop-down (optionally), tabbed, terminal for > Wayland! Obligatory screenshoot: http://i.imgur.com/OpOvxHK.png > > It's a Qt5 client, and uses libtsm for the background work. Given > Wayland clients don't know where they are nor they can tell the > compositor where they want to be I came up with a draft of a > protocol[0] where the client sends a surface and the server then > arranges for showing and hiding it. > There are some things yet to solve though. The biggest one is the > binding to show/hide the surface. Like, should the client or the > server dictate what binding to use? Should it allow many drop-down > clients to exist at the same time? To be visible at the same time? > > I've implemented the protocol in my shell plugin for Weston, > 'Nuclear'[1], with an hardcoded F11 binding. > > Termistor is still lacking many features, the selection for one, but > this is yet another step to ditching X for me. Nice to see this getting somewhere, looks quite promising! If you have questions regarding libtsm, let me know. I have skimmed through your code and the Screen object is actually not needed anymore. Since libtsm-3, we have ageing support in libtsm so it only renders changed lines. I rewrote wlterm [1] to use gtk+ and it now serves as minimal libtsm example (in case you want some reference code). I'm looking forward to further improvements. If something's missing, feel free to send me patches. Thanks David [1] wlterm: http://www.freedesktop.org/wiki/Software/kmscon/wlterm/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] logind: delay wakeup until DRM-device is resumed
Hi On Tue, Dec 3, 2013 at 10:42 PM, Kristian Høgsberg wrote: > On Sat, Nov 30, 2013 at 2:25 AM, David Herrmann wrote: >> The logind API was designed to allow any kind of devices and any number of >> devices. It has no idea of "main DRM device" or similar. However, the >> weston DRM backend was designed with a single DRM device as master. >> Therefore, we wake it up unconditionally on session-wakeup. But this may >> fail with logind as a session may be awake, but not all devices have been >> resumed, yet. >> >> Therefore, we change the weston-logind backend to deal with this case >> correctly. Instead of waking up the compositor on session-wakeup, we wait >> for the main DRM device to wake up. Once we get the event, we notify the >> compositor. >> >> For sleep, we reverse this logic. On *any* of the following events we >> tell the compositor to go to sleep: >> - Session gets inactive >> - DRM device gets inactive >> - DRM device is removed >> This guarantees, that weston is only active if *both*, the session and the >> main DRM device are awake/active. >> >> Note that we could actually rely solely on the DRM-device Pause/Resume >> events from logind and drop all the Active-Prop-Changed handling. logind >> guarantees proper ordering of both. However, in case we ever change weston >> to support multiple GPUs, we need the per-device notification. Thus, keep >> the code. This also makes weston more fail-safe in case logind fails to >> send the PauseDevice event (for whatever reason..). > > This explains the intermittent pageflip failures I was seeing. The > patch makes sense and makes VT switching work almost reliably. The > one missing thing is that occasionally my pointer doesn't work. It > looks like it remains locked by the X driver, and since it's only my > touchpad (keyboard always works) I'm guessing it's a > xf86-input-synaptics problem. It happens with weston-launch too, but > it doesn't look like a race. I can reproduce with just VT switching > from X to a VT and running evtest. That is, the device remains locked > long enough for me to type evtest, select the device and then see the > "Device is grabbed..." message. It doesn't get ungrabbed until I VT > switch back to X and then back to the VT. > > At this point I'm calling it a synaptics bug and merging your patch. You can set: Option "GrabEventDevice" "no" in the synaptics xorg config, btw. I tried reading through the synaptics code but couldn't find anything related to that bug. Hmm.. but I'm not really familiar with the xinput drivers code base.. Thanks for merging! Now everything should be in-place of the logind work. A bunch of changes for CONFIG_VT=n will be needed, but I'm working on that. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] logind: delay wakeup until DRM-device is resumed
The logind API was designed to allow any kind of devices and any number of
devices. It has no idea of "main DRM device" or similar. However, the
weston DRM backend was designed with a single DRM device as master.
Therefore, we wake it up unconditionally on session-wakeup. But this may
fail with logind as a session may be awake, but not all devices have been
resumed, yet.
Therefore, we change the weston-logind backend to deal with this case
correctly. Instead of waking up the compositor on session-wakeup, we wait
for the main DRM device to wake up. Once we get the event, we notify the
compositor.
For sleep, we reverse this logic. On *any* of the following events we
tell the compositor to go to sleep:
- Session gets inactive
- DRM device gets inactive
- DRM device is removed
This guarantees, that weston is only active if *both*, the session and the
main DRM device are awake/active.
Note that we could actually rely solely on the DRM-device Pause/Resume
events from logind and drop all the Active-Prop-Changed handling. logind
guarantees proper ordering of both. However, in case we ever change weston
to support multiple GPUs, we need the per-device notification. Thus, keep
the code. This also makes weston more fail-safe in case logind fails to
send the PauseDevice event (for whatever reason..).
---
src/logind-util.c | 58 +++
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/src/logind-util.c b/src/logind-util.c
index 5d163a6..40d811b 100644
--- a/src/logind-util.c
+++ b/src/logind-util.c
@@ -44,6 +44,8 @@
#include "dbus.h"
#include "logind-util.h"
+#define DRM_MAJOR 226
+
#ifndef KDSKBMUTE
#define KDSKBMUTE 0x4B51
#endif
@@ -275,10 +277,10 @@ weston_logind_activate_vt(struct weston_logind *wl, int
vt)
static void
weston_logind_set_active(struct weston_logind *wl, bool active)
{
- if (active)
- wl->compositor->session_active = 1;
- else
- wl->compositor->session_active = 0;
+ if (!wl->compositor->session_active == !active)
+ return;
+
+ wl->compositor->session_active = active;
wl_signal_emit(&wl->compositor->session_signal,
wl->compositor);
@@ -314,7 +316,8 @@ get_active_cb(DBusPendingCall *pending, void *data)
goto err_unref;
dbus_message_iter_get_basic(&sub, &b);
- weston_logind_set_active(wl, b);
+ if (!b)
+ weston_logind_set_active(wl, false);
err_unref:
dbus_message_unref(m);
@@ -428,7 +431,8 @@ property_changed(struct weston_logind *wl, DBusMessage *m)
if (!strcmp(name, "Active")) {
if (dbus_message_iter_get_arg_type(&entry) ==
DBUS_TYPE_BOOLEAN) {
dbus_message_iter_get_basic(&entry, &b);
- weston_logind_set_active(wl, b);
+ if (!b)
+ weston_logind_set_active(wl, false);
return;
}
}
@@ -478,31 +482,43 @@ device_paused(struct weston_logind *wl, DBusMessage *m)
/* "pause" means synchronous pausing. Acknowledge it unconditionally
* as we support asynchronous device shutdowns, anyway.
-* "force" means asynchronous pausing. We ignore it as the following
-* session-deactivation will suffice as notification.
-* "gone" means the device is gone. We ignore it as we receive a
-* udev notification, anyway. */
+* "force" means asynchronous pausing.
+* "gone" means the device is gone. We handle it the same as "force" as
+* a following udev event will be caught, too.
+*
+* If it's our main DRM device, tell the compositor to go asleep. */
if (!strcmp(type, "pause"))
weston_logind_pause_device_complete(wl, major, minor);
+
+ if (major == DRM_MAJOR)
+ weston_logind_set_active(wl, false);
}
static void
device_resumed(struct weston_logind *wl, DBusMessage *m)
{
- /*
-* DeviceResumed messages provide us a new file-descriptor for
+ bool r;
+ uint32_t major;
+
+ r = dbus_message_get_args(m, NULL,
+ DBUS_TYPE_UINT32, &major,
+ /*DBUS_TYPE_UINT32, &minor,
+ DBUS_TYPE_UNIX_FD, &fd,*/
+ DBUS_TYPE_INVALID);
+ if (!r) {
+ weston_log("logind: cannot parse ResumeDevice dbus signal\n");
+ return;
+ }
+
+ /* DeviceResumed messages provide us a new file-descriptor for
* resumed devices. For DRM devices it's the same as before, for evdev
* devices it's a new open-file. As we reopen evdev devices, anyway,
-* there is no need for us to handle this event. If we ever optimize
-* our e
[PATCH] logind: change to -1+errno
Set errno and return -1 in public API calls like all other weston code
does. Most systemd+dbus calls return negative error-codes instead of -1
and setting errno. Thus, we need to explicitly set errno before returning.
Also note that we must set errno _after_ the cleanup path. Calling
functions like close() in the cleanup path might overwrite errno (which is
not what we want). So protect errno until the final return -1;
---
src/logind-util.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/logind-util.c b/src/logind-util.c
index 6bd0c26..d71613a 100644
--- a/src/logind-util.c
+++ b/src/logind-util.c
@@ -168,9 +168,11 @@ weston_logind_open(struct weston_logind *wl, const char
*path,
r = stat(path, &st);
if (r < 0)
- return -errno;
- if (!S_ISCHR(st.st_mode))
- return -ENODEV;
+ return -1;
+ if (!S_ISCHR(st.st_mode)) {
+ errno = ENODEV;
+ return -1;
+ }
fd = weston_logind_take_device(wl, major(st.st_rdev),
minor(st.st_rdev), NULL);
@@ -220,7 +222,8 @@ err_close:
close(fd);
weston_logind_release_device(wl, major(st.st_rdev),
minor(st.st_rdev));
- return r;
+ errno = -r;
+ return -1;
}
WL_EXPORT void
@@ -263,7 +266,7 @@ weston_logind_activate_vt(struct weston_logind *wl, int vt)
r = ioctl(wl->vt, VT_ACTIVATE, vt);
if (r < 0)
- return -errno;
+ return -1;
return 0;
}
@@ -898,7 +901,8 @@ err_wl:
free(wl);
err_out:
weston_log("logind: cannot setup systemd-logind helper (%d), using
legacy fallback\n", r);
- return r;
+ errno = -r;
+ return -1;
}
WL_EXPORT void
--
1.8.4.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] logind: Use dbus_bool_t for bool types in dbus calls
Hi
On Thu, Nov 21, 2013 at 1:39 AM, Kristian Høgsberg wrote:
> The gcc built-in 'bool' type is not the same size as dbus_bool_t, which is
> an uint32_t. Passing a pointer to bool where dbus expects a uint32_t *
> doesn't work.
Nice catch! I hate dbus for that type.. happens to me all the time.
Reviewed-by: David Herrmann
> ---
> src/logind-util.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> David,
>
> This fixes a crash that Artie hit when testing this. Btw, did you get
> a chance to update the logind error paths to return -1 and set errno
> like we discussed?
I tried that, but systemd and dbus both return negative error codes
instead of errno+-1. So I have to change like 90 places to do:
errno = -r;
r = -1;
I can do that, but I thought it looked ugly. As a compromise, I can
only make the public logind-functions do that in the error-path? That
would be only 5 places. Comments?
Thanks
David
> diff --git a/src/logind-util.c b/src/logind-util.c
> index 6bd0c26..a58265c 100644
> --- a/src/logind-util.c
> +++ b/src/logind-util.c
> @@ -69,8 +69,9 @@ weston_logind_take_device(struct weston_logind *wl,
> uint32_t major,
> uint32_t minor, bool *paused_out)
> {
> DBusMessage *m, *reply;
> - bool b, paused;
> + bool b;
> int r, fd;
> + dbus_bool_t paused;
>
> m = dbus_message_new_method_call("org.freedesktop.login1",
> wl->spath,
> @@ -287,7 +288,7 @@ get_active_cb(DBusPendingCall *pending, void *data)
> DBusMessage *m;
> DBusMessageIter iter, sub;
> int type;
> - bool b;
> + dbus_bool_t b;
>
> dbus_pending_call_unref(wl->pending_active);
> wl->pending_active = NULL;
> --
> 1.8.3.1
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] clients: add simple-dmabuf
Hi Axel On Mon, Oct 28, 2013 at 12:34 AM, Axel Davy wrote: > > On 22/10/2013 17:23, David Herrmann wrote : > > Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on > the render-node. So if someone else tests this, you might need the > same hacks. I will try to find the code in mesa that requires this. > > David > > > This comes from 'intel_region_alloc_for_handle', which is called in > 'intel_process_dri2_buffer'. > > I've just talked with Christopher James Halse Rogers, and he already made > patches that should solve that. > > The patches to support driImage version 7 were posted recently on Mesa, > > And his older patches (probably need rebasing): > https://github.com/RAOF/mesa/commit/cc797647eaa0e59929eca09ad1c5936cab74144b > https://github.com/RAOF/mesa/commit/1ff8df28f25f98b2e4a12f7fb3085b7d0adbfdf3 > https://github.com/RAOF/mesa/commit/59e6361e9c76bb32c3fe96482ae0b31493dc3b3c > > Combined with setting the name field to null (instead of generating a name) > and setting the fd field to a prime dma-buf when creating a buffer (in > get_back_bo), > it should avoid using names at all, and use dma-buf in Mesa, thus enabling > using render-nodes with Mesa. Yepp, exactly these patches are needed! I don't know who it was I talked to in #intel-gfx, but some-one said he's working on it. Note that for dma-buf we're still missing allocation negotiation and sync fences. But these are also being worked on. With these patches (and your name=0; init thing) it works great. There're visible sync issues (really awful tearing, need to look into that), but apart from that it's fine. Regarding your earlier mail: We tried to _not_ support flink and friends on render-nodes. Yes, we could have provided some dummy ioctls to trick user-space, and yes, it would probably have worked well. But we intentionally tried to break the API to maybe some day be able to drop it. If we keep dummies, we never know who's still using it. If we don't, we simply say render-nodes are DRM-2.0 and be done with it. Thanks for your investigations! David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] compositor: finish frame if redraw fails
Hi On Tue, Oct 22, 2013 at 9:45 PM, Kristian Høgsberg wrote: > On Tue, Oct 22, 2013 at 05:11:26PM +0200, David Herrmann wrote: >> If we are about to finish a frame, but a redraw is pending and we let the >> compositor redraw, we need to check for errors. If the redraw fails and >> the backend cannot schedule a page-flip, we need to finish the frame, >> anyway. >> >> All backends except DRM use a timer to schedule frames. Hence, they cannot >> fail. But for DRM, we need to be able to handle drmModePageFlip() failures >> in case access got revoked. >> >> This fixes a bug where logind+drm caused keyboard input to be missed as we >> didn't reenable it after a failed page-flip during deactivation. > > Yes, that's better, applied both of these patches. Aside from being > unable to turn off sprites and hw cursor, the async deactivate also > means that we can lose drm master at any time, in particular between > starting repaint and pageflip. So we need to handle this better and I > think these two patches covers it. > > There's one last thing that doesn't quite work yet - when I switch to > weston, it doesn't immediately (re)set the current framebuffers. I > have to trigger a repaint by moving the mouse or such. I'm not sure > why that doesn't work, we still have the call to > drm_compositor_set_modes() and that should run with drm master set and > restore the last mode and buffer. It works for me. Does the log show anything? Thanks for testing! Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] clients: add simple-dmabuf
Hi On Mon, Oct 21, 2013 at 11:32 PM, David Herrmann wrote: > simple-dmabuf is an example client which shows how to write wayland > clients that use render-nodes for hardware-accelerated rendering and pass > the buffer via dmabuf to the compositor. No mesa/EGL extensions are > needed! Instead we pass dmabufs as wl_shm buffers to the compositors. This > allows us to use hardware-accelerated rendering even with fbdev or other > backends. Hurray! > > This still contains some hacks and is more a proof-of-concept than > something useful. However, it shows what render-nodes allow us to do > without modifying the compositor at all. > > This example requires a 3.12-rc kernel with drm.rnodes=1 on the kernel > command line (must be set during boot!). Furthermore, this currently only > works with drivers that implement dmabuf-mmap (which is rcar-du, shmob, > omapdrm and others). I have some hacks which implement it for i915 (but > flushing seems to not work..). > > I haven't succeeded in making rendering work with i915. I currently have > no access to other drivers so any further testing/debugging welcome. We > either still miss some render-nodes ioctls that are needed by mesa (but I > didn't get any mesa errors..) or my i915-dmabuf-mmap is just wrong. > If someone gets this working on a specific card (working means non-black > window), please let me know. Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on the render-node. So if someone else tests this, you might need the same hacks. I will try to find the code in mesa that requires this. David > --- > clients/.gitignore | 1 + > clients/Makefile.am | 7 +- > clients/simple-dmabuf.c | 675 > > configure.ac| 2 +- > 4 files changed, 683 insertions(+), 2 deletions(-) > create mode 100644 clients/simple-dmabuf.c > > diff --git a/clients/.gitignore b/clients/.gitignore > index 23959cc..b77b537 100644 > --- a/clients/.gitignore > +++ b/clients/.gitignore > @@ -11,6 +11,7 @@ weston-image > weston-nested > weston-nested-client > weston-resizor > +weston-simple-dmabuf > weston-simple-egl > weston-simple-shm > weston-simple-touch > diff --git a/clients/Makefile.am b/clients/Makefile.am > index 4f9dc48..39dca7f 100644 > --- a/clients/Makefile.am > +++ b/clients/Makefile.am > @@ -56,11 +56,16 @@ endif > > if BUILD_SIMPLE_EGL_CLIENTS > simple_egl_clients_programs = \ > - weston-simple-egl > + weston-simple-egl \ > + weston-simple-dmabuf > > weston_simple_egl_SOURCES = simple-egl.c > weston_simple_egl_CPPFLAGS = $(SIMPLE_EGL_CLIENT_CFLAGS) > weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm > + > +weston_simple_dmabuf_SOURCES = simple-dmabuf.c > +weston_simple_dmabuf_CPPFLAGS = $(SIMPLE_EGL_CLIENT_CFLAGS) > +weston_simple_dmabuf_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm > endif > > if BUILD_CLIENTS > diff --git a/clients/simple-dmabuf.c b/clients/simple-dmabuf.c > new file mode 100644 > index 000..570c929 > --- /dev/null > +++ b/clients/simple-dmabuf.c > @@ -0,0 +1,675 @@ > +/* > + * Copyright © 2012-2013 David Herrmann > + * > + * 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. > + */ > + > +/* > + * Simple dmabuf/render-nodes Client > + * This is a simple example client which uses dmabuf to pass buffers via > wl_shm > + * (instead of wl_drm or other EGL extensions) to the compositor. To render > the > + * images, we use DRM render-nodes or sof
[PATCH 1/2] compositor-drm: finish frame if initial page-flip fails
If the initial page-flip fails, immediately finish the frame to avoid
being stuck in the given frame. We already do this if we have no fbo
available. Now we do the same if the page-flip fails.
---
src/compositor-drm.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index cbdbb3c..8a70674 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -674,7 +674,7 @@ drm_output_start_repaint_loop(struct weston_output
*output_base)
struct drm_compositor *compositor = (struct drm_compositor *)
output_base->compositor;
uint32_t fb_id;
-
+ uint32_t msec;
struct timespec ts;
if (output->destroy_pending)
@@ -682,12 +682,7 @@ drm_output_start_repaint_loop(struct weston_output
*output_base)
if (!output->current) {
/* We can't page flip if there's no mode set */
- uint32_t msec;
-
- clock_gettime(compositor->clock, &ts);
- msec = ts.tv_sec * 1000 + ts.tv_nsec / 100;
- weston_output_finish_frame(output_base, msec);
- return;
+ goto finish_frame;
}
fb_id = output->current->fb_id;
@@ -695,8 +690,16 @@ drm_output_start_repaint_loop(struct weston_output
*output_base)
if (drmModePageFlip(compositor->drm.fd, output->crtc_id, fb_id,
DRM_MODE_PAGE_FLIP_EVENT, output) < 0) {
weston_log("queueing pageflip failed: %m\n");
- return;
+ goto finish_frame;
}
+
+ return;
+
+finish_frame:
+ /* if we cannot page-flip, immediately finish frame */
+ clock_gettime(compositor->clock, &ts);
+ msec = ts.tv_sec * 1000 + ts.tv_nsec / 100;
+ weston_output_finish_frame(output_base, msec);
}
static void
--
1.8.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] compositor: finish frame if redraw fails
If we are about to finish a frame, but a redraw is pending and we let the
compositor redraw, we need to check for errors. If the redraw fails and
the backend cannot schedule a page-flip, we need to finish the frame,
anyway.
All backends except DRM use a timer to schedule frames. Hence, they cannot
fail. But for DRM, we need to be able to handle drmModePageFlip() failures
in case access got revoked.
This fixes a bug where logind+drm caused keyboard input to be missed as we
didn't reenable it after a failed page-flip during deactivation.
---
src/compositor-drm.c | 20 ++--
src/compositor-fbdev.c| 4 +++-
src/compositor-headless.c | 4 ++--
src/compositor-rdp.c | 3 ++-
src/compositor-rpi.c | 3 ++-
src/compositor-wayland.c | 4 ++--
src/compositor-x11.c | 6 --
src/compositor.c | 14 +-
src/compositor.h | 2 +-
9 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 8a70674..9922708 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -576,7 +576,7 @@ drm_output_set_gamma(struct weston_output *output_base,
weston_log("set gamma failed: %m\n");
}
-static void
+static int
drm_output_repaint(struct weston_output *output_base,
pixman_region32_t *damage)
{
@@ -588,12 +588,12 @@ drm_output_repaint(struct weston_output *output_base,
int ret = 0;
if (output->destroy_pending)
- return;
+ return -1;
if (!output->next)
drm_output_render(output, damage);
if (!output->next)
- return;
+ return -1;
mode = container_of(output->base.current_mode, struct drm_mode, base);
if (!output->current) {
@@ -603,7 +603,7 @@ drm_output_repaint(struct weston_output *output_base,
&mode->mode_info);
if (ret) {
weston_log("set mode failed: %m\n");
- return;
+ goto err_pageflip;
}
output_base->set_dpms(output_base, WESTON_DPMS_ON);
}
@@ -612,7 +612,7 @@ drm_output_repaint(struct weston_output *output_base,
output->next->fb_id,
DRM_MODE_PAGE_FLIP_EVENT, output) < 0) {
weston_log("queueing pageflip failed: %m\n");
- return;
+ goto err_pageflip;
}
output->page_flip_pending = 1;
@@ -664,7 +664,15 @@ drm_output_repaint(struct weston_output *output_base,
output->vblank_pending = 1;
}
- return;
+ return 0;
+
+err_pageflip:
+ if (output->next) {
+ drm_output_release_fb(output, output->next);
+ output->next = NULL;
+ }
+
+ return -1;
}
static void
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 80e708d..29de1b8 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -196,7 +196,7 @@ fbdev_output_repaint_pixman(struct weston_output *base,
pixman_region32_t *damag
100 / output->mode.refresh);
}
-static void
+static int
fbdev_output_repaint(struct weston_output *base, pixman_region32_t *damage)
{
struct fbdev_output *output = to_fbdev_output(base);
@@ -214,6 +214,8 @@ fbdev_output_repaint(struct weston_output *base,
pixman_region32_t *damage)
wl_event_source_timer_update(output->finish_frame_timer,
100 / output->mode.refresh);
}
+
+ return 0;
}
static int
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 2a0b0c3..9d9f6dd 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -60,7 +60,7 @@ finish_frame_handler(void *data)
return 1;
}
-static void
+static int
headless_output_repaint(struct weston_output *output_base,
pixman_region32_t *damage)
{
@@ -74,7 +74,7 @@ headless_output_repaint(struct weston_output *output_base,
wl_event_source_timer_update(output->finish_frame_timer, 16);
- return;
+ return 0;
}
static void
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 69f1d04..8a302f8 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -302,7 +302,7 @@ rdp_output_start_repaint_loop(struct weston_output *output)
weston_output_finish_frame(output, msec);
}
-static void
+static int
rdp_output_repaint(struct weston_output *output_base, pixman_region32_t
*damage)
{
struct rdp_output *output = container_of(output_base, struct
rdp_output, base);
@@ -324,6 +324,7 @@ rdp_output_repaint(struct weston_output *output_base,
pixman_region32_t *damage)
&ec->primary_plane.damage, damage);
wl_event_source_timer_update(output->finish_frame_timer,
Re: [PATCH v2 4/4] launcher: add logind backend
Hi On Tue, Oct 22, 2013 at 1:56 AM, Kristian Høgsberg wrote: > On Tue, Oct 22, 2013 at 12:28:09AM +0200, David Herrmann wrote: >> Instead of connecting to weston-launch from launcher-util, we now try to >> connect to logind first. If logind provides session-devices, we use them. >> If not, we fall back to the old weston-launch facility. > > Thanks, I've committed this series and pushed it. There are still > issues with this - I tried vt switching to a text mode vt and it hung > up weston - but I want to merge this early on so we can start using it > and fix all the issues. To test this I manually edited my > /etc/dbus-1/system.d/a/src/login/org.freedesktop.login1.conf to the > effect of commit d7d1c8f983599dca6ee30229375215978657c072 from > systemd. I think we should add new wl_event_loop API instead of using > the dummy eventfd. Finally, we use return -1 and setting errno in > wayland/weston, not return -ENOMEM. The VT issue only happens if you switch VTs while weston is rendering. I was able to trigger it myself. The problem is that drmModePageFlip() fails and we never call weston_output_finish_frame(), thus never re-enabling input-handling. I fixed that and will send the patches after this mail. Btw., if you lock-up weston like this, you can still ssh into your machine and run "sudo chvt 7" and this will work. That's the beauty of logind-util.c. errno/-1.. whoops, totally forgot about that. Will fix it up. Regarding wl_event_loop.. what I need is wl_event_source_check() without an underlying source. So maybe I can allow wl_event_source_check() on idle sources? Currently not possible as idle-sources and wl_event_source_check() use the same list-head. > But let's fix these things and improve over the next few commits. I'm > excited to have the login support in weston and it's awesome to just > run 'weston' from the VT and have it come up running as 'krh'. It feels great, doesn't it? :) systemd-logind VT-handling is also almost finished. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 4/4] launcher: add logind backend
til.h
index 9de5237..d5b2fc9 100644
--- a/src/launcher-util.h
+++ b/src/launcher-util.h
@@ -30,7 +30,8 @@
struct weston_launcher;
struct weston_launcher *
-weston_launcher_connect(struct weston_compositor *compositor, int tty);
+weston_launcher_connect(struct weston_compositor *compositor, int tty,
+ const char *seat_id);
void
weston_launcher_destroy(struct weston_launcher *launcher);
diff --git a/src/logind-util.c b/src/logind-util.c
new file mode 100644
index 000..3766c58
--- /dev/null
+++ b/src/logind-util.c
@@ -0,0 +1,913 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "compositor.h"
+#include "dbus.h"
+#include "logind-util.h"
+
+#ifndef KDSKBMUTE
+#define KDSKBMUTE 0x4B51
+#endif
+
+struct weston_logind {
+ struct weston_compositor *compositor;
+ char *seat;
+ char *sid;
+ unsigned int vtnr;
+ int vt;
+ int kb_mode;
+ int sfd;
+ struct wl_event_source *sfd_source;
+
+ DBusConnection *dbus;
+ struct wl_event_source *dbus_ctx;
+ char *spath;
+ DBusPendingCall *pending_active;
+};
+
+static int
+weston_logind_take_device(struct weston_logind *wl, uint32_t major,
+ uint32_t minor, bool *paused_out)
+{
+ DBusMessage *m, *reply;
+ bool b, paused;
+ int r, fd;
+
+ m = dbus_message_new_method_call("org.freedesktop.login1",
+wl->spath,
+"org.freedesktop.login1.Session",
+"TakeDevice");
+ if (!m)
+ return -ENOMEM;
+
+ b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, &major,
+DBUS_TYPE_UINT32, &minor,
+DBUS_TYPE_INVALID);
+ if (!b) {
+ r = -ENOMEM;
+ goto err_unref;
+ }
+
+ reply = dbus_connection_send_with_reply_and_block(wl->dbus, m,
+ -1, NULL);
+ if (!reply) {
+ r = -ENODEV;
+ goto err_unref;
+ }
+
+ b = dbus_message_get_args(reply, NULL,
+ DBUS_TYPE_UNIX_FD, &fd,
+ DBUS_TYPE_BOOLEAN, &paused,
+ DBUS_TYPE_INVALID);
+ if (!b) {
+ r = -ENODEV;
+ goto err_reply;
+ }
+
+ r = fd;
+ if (paused_out)
+ *paused_out = paused;
+
+err_reply:
+ dbus_message_unref(reply);
+err_unref:
+ dbus_message_unref(m);
+ return r;
+}
+
+static void
+weston_logind_release_device(struct weston_logind *wl, uint32_t major,
+uint32_t minor)
+{
+ DBusMessage *m;
+ bool b;
+
+ m = dbus_message_new_method_call("org.freedesktop.login1",
+wl->spath,
+"org.freedesktop.login1.Session",
+"ReleaseDevice");
+ if (m) {
+ b = dbus_message_append_args(m,
+DBUS_TYPE_UINT32, &major,
+DBUS_TYPE_UINT32, &minor,
+DBUS_TYPE_INVALID);
+ if (b)
+ dbus_connecti
[PATCH v2 3/4] launcher: add weston_launcher_close() dummy
If you request a device via weston_launcher_open(), you should now release
it via weston_launcher_close() instead of close(). This is currently not
needed but will be required for logind devices.
---
src/launcher-util.c | 6 ++
src/launcher-util.h | 3 +++
src/udev-seat.c | 15 ++-
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/launcher-util.c b/src/launcher-util.c
index 4f77d11..8b496c8 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -174,6 +174,12 @@ weston_launcher_open(struct weston_launcher *launcher,
}
void
+weston_launcher_close(struct weston_launcher *launcher, int fd)
+{
+ close(fd);
+}
+
+void
weston_launcher_restore(struct weston_launcher *launcher)
{
struct vt_mode mode = { 0 };
diff --git a/src/launcher-util.h b/src/launcher-util.h
index 3e7ceb5..9de5237 100644
--- a/src/launcher-util.h
+++ b/src/launcher-util.h
@@ -39,6 +39,9 @@ int
weston_launcher_open(struct weston_launcher *launcher,
const char *path, int flags);
+void
+weston_launcher_close(struct weston_launcher *launcher, int fd);
+
int
weston_launcher_activate_vt(struct weston_launcher *launcher, int vt);
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 4ef7ff3..11a34fb 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -83,11 +83,11 @@ device_added(struct udev_device *udev_device, struct
udev_input *input)
device = evdev_device_create(&seat->base, devnode, fd);
if (device == EVDEV_UNHANDLED_DEVICE) {
- close(fd);
+ weston_launcher_close(c->launcher, fd);
weston_log("not using input device '%s'.\n", devnode);
return 0;
} else if (device == NULL) {
- close(fd);
+ weston_launcher_close(c->launcher, fd);
weston_log("failed to create input device '%s'.\n", devnode);
return 0;
}
@@ -216,9 +216,11 @@ evdev_udev_handler(int fd, uint32_t mask, void *data)
if (!strcmp(device->devnode, devnode)) {
weston_log("input device %s, %s
removed\n",
device->devname,
device->devnode);
+
weston_launcher_close(input->compositor->launcher,
+ device->fd);
evdev_device_destroy(device);
- break;
- }
+ break;
+ }
}
}
@@ -273,8 +275,11 @@ udev_input_remove_devices(struct udev_input *input)
struct udev_seat *seat;
wl_list_for_each(seat, &input->compositor->seat_list, base.link) {
- wl_list_for_each_safe(device, next, &seat->devices_list, link)
+ wl_list_for_each_safe(device, next, &seat->devices_list, link) {
+ weston_launcher_close(input->compositor->launcher,
+ device->fd);
evdev_device_destroy(device);
+ }
if (seat->base.keyboard)
notify_keyboard_focus_out(&seat->base);
--
1.8.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 2/4] dbus: add dbus-match helpers
These helpers simplify adding dbus-matches by allowing var-arg arguments
to assemble the matching rules.
---
src/dbus.c | 68 ++
src/dbus.h | 40
2 files changed, 108 insertions(+)
diff --git a/src/dbus.c b/src/dbus.c
index 4de8c9c..a1abbd5 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -334,3 +334,71 @@ void weston_dbus_close(DBusConnection *c, struct
wl_event_source *ctx)
dbus_connection_close(c);
dbus_connection_unref(c);
}
+
+int weston_dbus_add_match(DBusConnection *c, const char *format, ...)
+{
+ DBusError err;
+ int r;
+ va_list list;
+ char *str;
+
+ va_start(list, format);
+ r = vasprintf(&str, format, list);
+ va_end(list);
+
+ if (r < 0)
+ return -ENOMEM;
+
+ dbus_error_init(&err);
+ dbus_bus_add_match(c, str, &err);
+ free(str);
+ if (dbus_error_is_set(&err)) {
+ dbus_error_free(&err);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+int weston_dbus_add_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path)
+{
+ return weston_dbus_add_match(c,
+"type='signal',"
+"sender='%s',"
+"interface='%s',"
+"member='%s',"
+"path='%s'",
+sender, iface, member, path);
+}
+
+void weston_dbus_remove_match(DBusConnection *c, const char *format, ...)
+{
+ int r;
+ va_list list;
+ char *str;
+
+ va_start(list, format);
+ r = vasprintf(&str, format, list);
+ va_end(list);
+
+ if (r < 0)
+ return;
+
+ dbus_bus_remove_match(c, str, NULL);
+ free(str);
+}
+
+void weston_dbus_remove_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path)
+{
+ return weston_dbus_remove_match(c,
+ "type='signal',"
+ "sender='%s',"
+ "interface='%s',"
+ "member='%s',"
+ "path='%s'",
+ sender, iface, member, path);
+}
diff --git a/src/dbus.h b/src/dbus.h
index 90ab8f6..06fe762 100644
--- a/src/dbus.h
+++ b/src/dbus.h
@@ -62,6 +62,46 @@ int weston_dbus_open(struct wl_event_loop *loop, DBusBusType
bus,
*/
void weston_dbus_close(DBusConnection *c, struct wl_event_source *ctx);
+/*
+ * weston_dbus_add_match() - Add dbus match
+ *
+ * Configure a dbus-match on the given dbus-connection. This match is saved
+ * on the dbus-server as long as the connection is open. See dbus-manual
+ * for information. Compared to the dbus_bus_add_match() this allows a
+ * var-arg formatted match-string.
+ */
+int weston_dbus_add_match(DBusConnection *c, const char *format, ...);
+
+/*
+ * weston_dbus_add_match_signal() - Add dbus signal match
+ *
+ * Same as weston_dbus_add_match() but does the dbus-match formatting for
+ * signals internally.
+ */
+int weston_dbus_add_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path);
+
+/*
+ * weston_dbus_remove_match() - Remove dbus match
+ *
+ * Remove a previously configured dbus-match from the dbus server. There is
+ * no need to remove dbus-matches if you close the connection, anyway.
+ * Compared to dbus_bus_remove_match() this allows a var-arg formatted
+ * match string.
+ */
+void weston_dbus_remove_match(DBusConnection *c, const char *format, ...);
+
+/*
+ * weston_dbus_remove_match_signal() - Remove dbus signal match
+ *
+ * Same as weston_dbus_remove_match() but does the dbus-match formatting for
+ * signals internally.
+ */
+void weston_dbus_remove_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path);
+
#endif /* HAVE_DBUS */
#endif // _WESTON_DBUS_H_
--
1.8.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 1/4] Add optional dbus helpers
This adds optional libdbus integration for weston. If libdbus is available
and not disabled via --disable-dbus during weston build, we now provide
basic DBusConnection main-loop integration for weston.
The dbus.c file provides a new helper to integrate any DBusConnection
object into a wl_event_loop object. This avoids any glib/qt/..
dependencies but instead only uses the low-level libdbus library.
Note that we do not provide dummy fallbacks for dbus helpers in case
dbus-support is disabled. The reason for that is that you need dbus/dbus.h
for nearly any operation you want to do via dbus. Therefore, only the most
basic helpers which can be used independently provide a "static inline"
dummy fallback to avoid #ifdef all over the code.
---
configure.ac| 23
src/Makefile.am | 8 ++
src/dbus.c | 336
src/dbus.h | 67 +++
4 files changed, 434 insertions(+)
create mode 100644 src/dbus.c
create mode 100644 src/dbus.h
diff --git a/configure.ac b/configure.ac
index 950086d..2661aad 100644
--- a/configure.ac
+++ b/configure.ac
@@ -379,6 +379,28 @@ if test "x$enable_colord" != "xno"; then
fi
AM_CONDITIONAL(ENABLE_COLORD, test "x$enable_colord" = "xyes")
+# dbus support
+AC_ARG_ENABLE(dbus,
+ AS_HELP_STRING([--disable-dbus],
+ [do not build with dbus support]),,
+ enable_dbus=auto)
+if test "x$enable_dbus" != "xno"; then
+PKG_CHECK_MODULES(DBUS,
+ dbus-1 >= 1.6,
+ have_dbus=yes,
+ have_dbus=no)
+if test "x$have_dbus" = "xno" -a "x$enable_dbus" = "xyes"; then
+AC_MSG_ERROR([dbus support explicitly requested, but libdbus
couldn't be found])
+fi
+if test "x$have_dbus" = "xyes"; then
+enable_dbus=yes
+AC_DEFINE([HAVE_DBUS], [1], [Build with dbus support])
+else
+enable_dbus=no
+fi
+fi
+AM_CONDITIONAL(ENABLE_DBUS, test "x$enable_dbus" = "xyes")
+
AC_ARG_ENABLE(wcap-tools, [ --disable-wcap-tools],, enable_wcap_tools=yes)
AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
if test x$enable_wcap_tools = xyes; then
@@ -467,6 +489,7 @@ AC_MSG_RESULT([
EGL ${enable_egl}
libxkbcommon${enable_xkbcommon}
XWayland${enable_xwayland}
+ dbus${enable_dbus}
Build wcap utility ${enable_wcap_tools}
Build Tablet Shell ${enable_tablet_shell}
diff --git a/src/Makefile.am b/src/Makefile.am
index b0eae7c..8cd7cca 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -49,6 +49,14 @@ weston_SOURCES = \
weston-launch.h \
weston-egl-ext.h
+if ENABLE_DBUS
+weston_SOURCES += \
+ dbus.h \
+ dbus.c
+weston_CFLAGS += $(DBUS_CFLAGS)
+weston_LDADD += $(DBUS_LIBS)
+endif
+
git-version.h : .FORCE
$(AM_V_GEN)(echo "#define BUILD_ID \"$(shell git
--git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git
--git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')\"" > $@-new; \
cmp -s $@ $@-new || cp $@-new $@; \
diff --git a/src/dbus.c b/src/dbus.c
new file mode 100644
index 000..4de8c9c
--- /dev/null
+++ b/src/dbus.c
@@ -0,0 +1,336 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * 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.
+ */
+
+/*
+ * DBus Helpers
+ * This file contain
[RFC] clients: add simple-dmabuf
simple-dmabuf is an example client which shows how to write wayland
clients that use render-nodes for hardware-accelerated rendering and pass
the buffer via dmabuf to the compositor. No mesa/EGL extensions are
needed! Instead we pass dmabufs as wl_shm buffers to the compositors. This
allows us to use hardware-accelerated rendering even with fbdev or other
backends. Hurray!
This still contains some hacks and is more a proof-of-concept than
something useful. However, it shows what render-nodes allow us to do
without modifying the compositor at all.
This example requires a 3.12-rc kernel with drm.rnodes=1 on the kernel
command line (must be set during boot!). Furthermore, this currently only
works with drivers that implement dmabuf-mmap (which is rcar-du, shmob,
omapdrm and others). I have some hacks which implement it for i915 (but
flushing seems to not work..).
I haven't succeeded in making rendering work with i915. I currently have
no access to other drivers so any further testing/debugging welcome. We
either still miss some render-nodes ioctls that are needed by mesa (but I
didn't get any mesa errors..) or my i915-dmabuf-mmap is just wrong.
If someone gets this working on a specific card (working means non-black
window), please let me know.
---
clients/.gitignore | 1 +
clients/Makefile.am | 7 +-
clients/simple-dmabuf.c | 675
configure.ac| 2 +-
4 files changed, 683 insertions(+), 2 deletions(-)
create mode 100644 clients/simple-dmabuf.c
diff --git a/clients/.gitignore b/clients/.gitignore
index 23959cc..b77b537 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -11,6 +11,7 @@ weston-image
weston-nested
weston-nested-client
weston-resizor
+weston-simple-dmabuf
weston-simple-egl
weston-simple-shm
weston-simple-touch
diff --git a/clients/Makefile.am b/clients/Makefile.am
index 4f9dc48..39dca7f 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -56,11 +56,16 @@ endif
if BUILD_SIMPLE_EGL_CLIENTS
simple_egl_clients_programs = \
- weston-simple-egl
+ weston-simple-egl \
+ weston-simple-dmabuf
weston_simple_egl_SOURCES = simple-egl.c
weston_simple_egl_CPPFLAGS = $(SIMPLE_EGL_CLIENT_CFLAGS)
weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
+
+weston_simple_dmabuf_SOURCES = simple-dmabuf.c
+weston_simple_dmabuf_CPPFLAGS = $(SIMPLE_EGL_CLIENT_CFLAGS)
+weston_simple_dmabuf_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
endif
if BUILD_CLIENTS
diff --git a/clients/simple-dmabuf.c b/clients/simple-dmabuf.c
new file mode 100644
index 000..570c929
--- /dev/null
+++ b/clients/simple-dmabuf.c
@@ -0,0 +1,675 @@
+/*
+ * Copyright © 2012-2013 David Herrmann
+ *
+ * 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.
+ */
+
+/*
+ * Simple dmabuf/render-nodes Client
+ * This is a simple example client which uses dmabuf to pass buffers via wl_shm
+ * (instead of wl_drm or other EGL extensions) to the compositor. To render the
+ * images, we use DRM render-nodes or software-rendering as fallback.
+ *
+ * Note that this is a very basic example how to use wl_shm to share buffers
+ * which were rendered using a dedicated GPU. No mesa/EGL internal extensions
+ * are required.
+ * However, this is *not* the recommended way to do it! The mesa/EGL extensions
+ * allow much better integration and control. This client serves as a
+ * proof-of-concept and generic HOWTO.
+ */
+
+#define EGL_EGLEXT_PROTOTYPES
+#define GL_GLEXT_PROTOTYPES
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* buffer objects */
+
+struct buffer {
+ struct window *window;
+ struct wl_buffer *buffer;
+
[PATCH] event-loop: fix blocking timerfd read
If we call wl_event_source_check() on a timerfd, our dispatcher will block
on the timerfd read(). Avoid calling read() if no epoll-event was
reported.
Note: The internal tick-count of a timerfd is never decreased. So once we
get signaled a read event, a following read() is guaranteed to succeed
_if_ no other operation is called on the timerfd in between. Therefore,
there is no need for us to make the read() non-blocking (even with
clock-changes we never block). However, to be safe for future changed,
just ignore EAGAIN safely.
Also remove the comment about read() failure. The only reasons the read
can currently fail is EINTR or invalid parameters. The latter cannot
happen in our setup so ignore it. EINTR shouldn't happen as
syscall-restart is the default behavior so we simply return if a user
changed it. Better safe than sorry.
Signed-off-by: David Herrmann
---
src/event-loop.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/event-loop.c b/src/event-loop.c
index d323601..d340e3c 100644
--- a/src/event-loop.c
+++ b/src/event-loop.c
@@ -172,10 +172,15 @@ wl_event_source_timer_dispatch(struct wl_event_source
*source,
uint64_t expires;
int len;
- len = read(source->fd, &expires, sizeof expires);
- if (len != sizeof expires)
- /* Is there anything we can do here? Will this ever happen? */
- fprintf(stderr, "timerfd read error: %m\n");
+ if (ep->events != 0) {
+ len = read(source->fd, &expires, sizeof expires);
+ if (len != sizeof expires) {
+ if (len >= 0 || (errno != EINTR && errno != EAGAIN))
+ fprintf(stderr,
+ "timerfd read error (%d): %m\n", len);
+ return 0;
+ }
+ }
return timer_source->func(timer_source->base.data);
}
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/7] Make weston spawn weston-launch
Hi On Tue, Oct 15, 2013 at 8:07 PM, Kristian Høgsberg wrote: > On Tue, Oct 15, 2013 at 02:29:58PM +0200, David Herrmann wrote: >> This is a rather complete rewrite of weston-launch. Instead of spawning >> weston from weston-launch, we do the inverse now. Whenever weston is >> spawned with a backend that uses launcher-util, we spawn weston-launch as >> child process. weston-launch still handles VT switching and open() for >> session-devices and passes them back to weston. >> >> However, this drops all PAM, --user and session handling from >> weston-launch. If we spawn weston-launch from weston, we cannot do any PAM >> handling as it wouldn't affect weston, anymore. But this doesn't hurt as >> the same effects can be achieved via "su", "sudo" or "/bin/login". There >> is no real reason to do this in weston. >> If you want weston to run in a new session, use one of these helpers to >> create the session and then spawn weston from within the new session. >> >> Some more differences are: >> >> (1) We have now two sockets from weston to weston-launch. One for OPEN and >> one for EVENTS. The reason for that is that if we send an OPEN request and >> weston-launch schedules some VT-EVENT before sending the OPEN response, >> launcher-util needs to handle the VT-EVENT from within >> weston_launcher_open(). This isn't very hard to do, but may cause weird >> side-effects as the callstack might already be an EVENT handling. There >> are other ways to handle that, but the simplest way is to have two >> independent queues. > > I thought I handled this in current weston-launch by scheduling an > idle callback to handle the event if I get an event while waiting for > a response. But I don't see the code there, so I must have failed to > do that, but I talked to Giovanni about this for mutter-launch and he > did it there. Using two socketpairs has much the same effect and > shouldn't be a big deal. Problem with idle-callback is that we can schedule it only once. So multiple events may be merged. It might work if we remember each event individually, but I thought two pipes is the easier way. >> (2) VT_ACTIVATE is privileged, so we pass the request to weston-launch >> which then issues the VT_ACTIVATE ioctl. > > Are you sure? I can login in text mode and use chvt to vt switch away > from that text login. I think if your tty is a vt and that vt is > currently active, you're allowed to switch away. That is, you can't > run on an inactive VT and then vt switch to your VT, but you're > allowed to switch away. Which is all weston needs and it's how > launcher-util.c currently does it. As for the initial VT switch to > the weston VT, that is done in weston-launch. > > Actually, I just tried to log in on vt2, do a "sleep 2; chvt 3" and > then switch to vt 1. After the two seconds I'm switched back to vt 2. > chvt isn't setuid and I run is as user krh. It fails under X because > it tries to open /prof/self/fd/0, which is the pty of your X terminal. > > But if I try > > [krh@tokamak weston]$ chvt 2 0 chvt: VT_ACTIVATE: Operation not permitted > > so I'm not really sure what the rules are. > > Mainly, I'd just like to not have this in the weston-launch protocol. > For logind it doesn't matter since we use session.Activate there, but > if we can keep the weston-launch case simpler by not having more > protocol than we need to, that's better. VT ioctls are allowed by: - CAP_SYS_TTY_CONFIG - processes with the VT as controlling-tty Problem with the latter is that only a single session can have a given TTY as controlling TTY. Overwriting this requires root. So if you start weston from within a shell on a VT, you cannot call setsid()+TIOCSCTTY from weston, as the shell still has the VT as controlling-TTY... That's why I thought the easiest way is to let weston-launch do that as root. >> (3) weston-launch is mandatory now. Every backend which uses launcher-util >> requires weston-launch now. However, setuid is *not* mandatory! If >> weston-launch does not have the setuid bit, you have to run weston as root >> (as usual). > > That's fine, the reason I kept the ability to run without > weston-launch was that having to run weston through weston-launch gets > in the way of debugging and testing. Now that we're running weston > directly even when it's using weston-launch, we can drop that code > path. Ok, Benjamin's comment actually made me reconsider this. If weston-launch is spawned by weston, any other session may also use weston-launch. I doubt there's a safe way for us to verify we
Re: [PATCH 7/7] launcher: add logind backend
Hi On Tue, Oct 15, 2013 at 8:47 PM, Kristian Høgsberg wrote: > On Tue, Oct 15, 2013 at 02:30:02PM +0200, David Herrmann wrote: >> Instead of spawning weston-launch from the launcher-util, we now try to >> connect to logind first. If logind provides session-devices, we use them. >> If not, we fall back to the old weston-launch facility. >> --- >> configure.ac | 1 + >> src/Makefile.am| 8 + >> src/compositor-drm.c | 2 +- >> src/compositor-fbdev.c | 2 +- >> src/compositor-rpi.c | 2 +- >> src/launcher-util.c| 40 ++- >> src/launcher-util.h| 3 +- >> src/logind-util.c | 913 >> + >> src/logind-util.h | 94 + >> 9 files changed, 1054 insertions(+), 11 deletions(-) >> create mode 100644 src/logind-util.c >> create mode 100644 src/logind-util.h > > I applied the whole patch series and stubbed out the call to > sd_session_get_vt() (instead of updating systemd), but I then get Cool, thanks for testing. > [11:35:04.658] logind: cannot take control over session 4 > > in the weston log and journalctl tells me > > Oct 15 11:34:52 tokamak.local dbus-daemon[444]: dbus[444]: [system] Rejected > send message, 2 matched rules; type="method_call", sender=":1.75" (uid=1000 > pid=17613 comm="weston --tty=2 ") interface="org.freedesktop.login1.Session" > member="TakeControl" error name="(unset)" requested_reply="0" > destination="org.freedesktop.login1" (uid=0 pid=441 > comm="/usr/lib/systemd/systemd-logind ") > Oct 15 11:34:52 tokamak.local dbus[444]: [system] Rejected send message, 2 > matched rules; type="method_call", sender=":1.75" (uid=1000 pid=17613 > comm="weston --tty=2 ") interface="org.freedesktop.login1.Session" > member="TakeControl" error name="(unset)" requested_reply="0" > destination="org.freedesktop.login1" (uid=0 pid=441 > comm="/usr/lib/systemd/systemd-logind ") whoops, You need to adjust /etc/dbus-1/system.d/org.freedesktop.login1.conf: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d7d1c8f983599dca6ee30229375215978657c072 I pushed the fix. I thought the dbus-policies are package-manager generated.. sorry. > Also, logind-util.c does all the vt setup and teardown, but I wonder > what happens if weston crashes. Will logind reset the vt (unmute, > KD_TEXT etc) or will the system get stuck? One of the benefits of the > recent weston-launch rewrite was that weston-launch will clean up if > weston crashes, which is much more reliable. I thought leaving the VT in VT_AUTO mode would be enough. Session-switching would still work. Then today I noticed that in VT_AUTO+KD_GRAPHICS the kernel *ignores* all VT-switch request.. *sigh* That means, for a crashing weston we can just recover the VT in logind (as Session.ReleaseControl() is implicitly called on dbus disconnect of session-controllers). However, for a hung session we either have to set VT_PROCESS in logind itself or add some recovery option. I don't know.. Have to think about it. Note that this is still rudimentary. The weston-launch rewrite should be fine, but the dbus+logind patches still need testing and extensions. Btw., I can run weston without setuid, without weston-launch and without root here. Feels awesome! Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 7/7] launcher: add logind backend
if (!message)
@@ -140,6 +145,9 @@ weston_launcher_open(struct weston_launcher *launcher,
void
weston_launcher_close(struct weston_launcher *launcher, int fd)
{
+ if (launcher->logind)
+ return weston_logind_close(launcher->logind, fd);
+
close(fd);
}
@@ -148,6 +156,9 @@ weston_launcher_restore(struct weston_launcher *launcher)
{
struct vt_mode mode = { 0 };
+ if (launcher->logind)
+ return weston_logind_restore(launcher->logind);
+
ioctl(launcher->tty, KDSKBMUTE, 0);
ioctl(launcher->tty, KDSKBMODE, launcher->kb_mode);
ioctl(launcher->tty, KDSETMODE, KD_TEXT);
@@ -197,6 +208,9 @@ weston_launcher_activate_vt(struct weston_launcher
*launcher, int vt)
ssize_t len;
struct weston_launcher_switchvt message;
+ if (launcher->logind)
+ return weston_logind_activate_vt(launcher->logind, vt);
+
/* VT_ACTIVATE is a privileged ioctl so ask weston-launch */
message.header.opcode = WESTON_LAUNCHER_SWITCHVT;
@@ -398,7 +412,8 @@ setup_tty(struct weston_launcher *wl, int ttyid)
}
struct weston_launcher *
-weston_launcher_connect(struct weston_compositor *compositor, int tty)
+weston_launcher_connect(struct weston_compositor *compositor, int tty,
+ const char *seat_id)
{
struct weston_launcher *launcher;
struct wl_event_loop *loop;
@@ -414,6 +429,12 @@ weston_launcher_connect(struct weston_compositor
*compositor, int tty)
launcher->fd = -1;
launcher->event_fd = -1;
+ r = weston_logind_connect(&launcher->logind, compositor, seat_id, tty);
+ if (r >= 0)
+ return launcher;
+
+ launcher->logind = NULL;
+
r = setup_tty(launcher, tty);
if (r < 0)
goto err_free;
@@ -448,11 +469,16 @@ err_free:
void
weston_launcher_destroy(struct weston_launcher *launcher)
{
- wl_list_remove(&launcher->launcher.link);
- wl_event_source_remove(launcher->source);
- close(launcher->event_fd);
- close(launcher->fd);
- weston_launcher_restore(launcher);
- close(launcher->tty);
+ if (launcher->logind) {
+ weston_logind_destroy(launcher->logind);
+ } else {
+ wl_list_remove(&launcher->launcher.link);
+ wl_event_source_remove(launcher->source);
+ close(launcher->event_fd);
+ close(launcher->fd);
+ weston_launcher_restore(launcher);
+ close(launcher->tty);
+ }
+
free(launcher);
}
diff --git a/src/launcher-util.h b/src/launcher-util.h
index 9de5237..d5b2fc9 100644
--- a/src/launcher-util.h
+++ b/src/launcher-util.h
@@ -30,7 +30,8 @@
struct weston_launcher;
struct weston_launcher *
-weston_launcher_connect(struct weston_compositor *compositor, int tty);
+weston_launcher_connect(struct weston_compositor *compositor, int tty,
+ const char *seat_id);
void
weston_launcher_destroy(struct weston_launcher *launcher);
diff --git a/src/logind-util.c b/src/logind-util.c
new file mode 100644
index 000..066f751
--- /dev/null
+++ b/src/logind-util.c
@@ -0,0 +1,913 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "compositor.h"
+#include "dbus.h"
+#include "logind-util.h"
+
+#ifndef KDSKBMUTE
+#define KDSKBMUTE 0x4B51
+#endif
+
+struct weston_logind {
+ struct weston_compositor *compositor;
+ ch
[PATCH 5/7] dbus: add dbus-match helpers
These helpers simplify adding dbus-matches by allowing var-arg arguments
to assemble the matching rules.
---
src/dbus.c | 68 ++
src/dbus.h | 40
2 files changed, 108 insertions(+)
diff --git a/src/dbus.c b/src/dbus.c
index 4de8c9c..a1abbd5 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -334,3 +334,71 @@ void weston_dbus_close(DBusConnection *c, struct
wl_event_source *ctx)
dbus_connection_close(c);
dbus_connection_unref(c);
}
+
+int weston_dbus_add_match(DBusConnection *c, const char *format, ...)
+{
+ DBusError err;
+ int r;
+ va_list list;
+ char *str;
+
+ va_start(list, format);
+ r = vasprintf(&str, format, list);
+ va_end(list);
+
+ if (r < 0)
+ return -ENOMEM;
+
+ dbus_error_init(&err);
+ dbus_bus_add_match(c, str, &err);
+ free(str);
+ if (dbus_error_is_set(&err)) {
+ dbus_error_free(&err);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+int weston_dbus_add_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path)
+{
+ return weston_dbus_add_match(c,
+"type='signal',"
+"sender='%s',"
+"interface='%s',"
+"member='%s',"
+"path='%s'",
+sender, iface, member, path);
+}
+
+void weston_dbus_remove_match(DBusConnection *c, const char *format, ...)
+{
+ int r;
+ va_list list;
+ char *str;
+
+ va_start(list, format);
+ r = vasprintf(&str, format, list);
+ va_end(list);
+
+ if (r < 0)
+ return;
+
+ dbus_bus_remove_match(c, str, NULL);
+ free(str);
+}
+
+void weston_dbus_remove_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path)
+{
+ return weston_dbus_remove_match(c,
+ "type='signal',"
+ "sender='%s',"
+ "interface='%s',"
+ "member='%s',"
+ "path='%s'",
+ sender, iface, member, path);
+}
diff --git a/src/dbus.h b/src/dbus.h
index 90ab8f6..06fe762 100644
--- a/src/dbus.h
+++ b/src/dbus.h
@@ -62,6 +62,46 @@ int weston_dbus_open(struct wl_event_loop *loop, DBusBusType
bus,
*/
void weston_dbus_close(DBusConnection *c, struct wl_event_source *ctx);
+/*
+ * weston_dbus_add_match() - Add dbus match
+ *
+ * Configure a dbus-match on the given dbus-connection. This match is saved
+ * on the dbus-server as long as the connection is open. See dbus-manual
+ * for information. Compared to the dbus_bus_add_match() this allows a
+ * var-arg formatted match-string.
+ */
+int weston_dbus_add_match(DBusConnection *c, const char *format, ...);
+
+/*
+ * weston_dbus_add_match_signal() - Add dbus signal match
+ *
+ * Same as weston_dbus_add_match() but does the dbus-match formatting for
+ * signals internally.
+ */
+int weston_dbus_add_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path);
+
+/*
+ * weston_dbus_remove_match() - Remove dbus match
+ *
+ * Remove a previously configured dbus-match from the dbus server. There is
+ * no need to remove dbus-matches if you close the connection, anyway.
+ * Compared to dbus_bus_remove_match() this allows a var-arg formatted
+ * match string.
+ */
+void weston_dbus_remove_match(DBusConnection *c, const char *format, ...);
+
+/*
+ * weston_dbus_remove_match_signal() - Remove dbus signal match
+ *
+ * Same as weston_dbus_remove_match() but does the dbus-match formatting for
+ * signals internally.
+ */
+void weston_dbus_remove_match_signal(DBusConnection *c, const char *sender,
+const char *iface, const char *member,
+const char *path);
+
#endif /* HAVE_DBUS */
#endif // _WESTON_DBUS_H_
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 6/7] launcher: add weston_launcher_close() dummy
If you request a device via weston_launcher_open(), you should now release
it via weston_launcher_close() instead of close(). This is currently not
needed but will be required for logind devices.
---
src/launcher-util.c | 6 ++
src/launcher-util.h | 3 +++
src/udev-seat.c | 15 ++-
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/launcher-util.c b/src/launcher-util.c
index 3f19083..30e62fc 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -138,6 +138,12 @@ weston_launcher_open(struct weston_launcher *launcher,
}
void
+weston_launcher_close(struct weston_launcher *launcher, int fd)
+{
+ close(fd);
+}
+
+void
weston_launcher_restore(struct weston_launcher *launcher)
{
struct vt_mode mode = { 0 };
diff --git a/src/launcher-util.h b/src/launcher-util.h
index 3e7ceb5..9de5237 100644
--- a/src/launcher-util.h
+++ b/src/launcher-util.h
@@ -39,6 +39,9 @@ int
weston_launcher_open(struct weston_launcher *launcher,
const char *path, int flags);
+void
+weston_launcher_close(struct weston_launcher *launcher, int fd);
+
int
weston_launcher_activate_vt(struct weston_launcher *launcher, int vt);
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 4ef7ff3..11a34fb 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -83,11 +83,11 @@ device_added(struct udev_device *udev_device, struct
udev_input *input)
device = evdev_device_create(&seat->base, devnode, fd);
if (device == EVDEV_UNHANDLED_DEVICE) {
- close(fd);
+ weston_launcher_close(c->launcher, fd);
weston_log("not using input device '%s'.\n", devnode);
return 0;
} else if (device == NULL) {
- close(fd);
+ weston_launcher_close(c->launcher, fd);
weston_log("failed to create input device '%s'.\n", devnode);
return 0;
}
@@ -216,9 +216,11 @@ evdev_udev_handler(int fd, uint32_t mask, void *data)
if (!strcmp(device->devnode, devnode)) {
weston_log("input device %s, %s
removed\n",
device->devname,
device->devnode);
+
weston_launcher_close(input->compositor->launcher,
+ device->fd);
evdev_device_destroy(device);
- break;
- }
+ break;
+ }
}
}
@@ -273,8 +275,11 @@ udev_input_remove_devices(struct udev_input *input)
struct udev_seat *seat;
wl_list_for_each(seat, &input->compositor->seat_list, base.link) {
- wl_list_for_each_safe(device, next, &seat->devices_list, link)
+ wl_list_for_each_safe(device, next, &seat->devices_list, link) {
+ weston_launcher_close(input->compositor->launcher,
+ device->fd);
evdev_device_destroy(device);
+ }
if (seat->base.keyboard)
notify_keyboard_focus_out(&seat->base);
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 4/7] Add optional dbus helpers
This adds optional libdbus integration for weston. If libdbus is available
and not disabled via --disable-dbus during weston build, we now provide
basic DBusConnection main-loop integration for weston.
The dbus.c file provides a new helper to integrate any DBusConnection
object into a wl_event_loop object. This avoids any glib/qt/..
dependencies but instead only uses the low-level libdbus library.
Note that we do not provide dummy fallbacks for dbus helpers in case
dbus-support is disabled. The reason for that is that you need dbus/dbus.h
for nearly any operation you want to do via dbus. Therefore, only the most
basic helpers which can be used independently provide a "static inline"
dummy fallback to avoid #ifdef all over the code.
---
configure.ac| 23
src/Makefile.am | 8 ++
src/dbus.c | 336
src/dbus.h | 67 +++
4 files changed, 434 insertions(+)
create mode 100644 src/dbus.c
create mode 100644 src/dbus.h
diff --git a/configure.ac b/configure.ac
index 93a38ac..643209c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -376,6 +376,28 @@ if test "x$enable_colord" != "xno"; then
fi
AM_CONDITIONAL(ENABLE_COLORD, test "x$enable_colord" = "xyes")
+# dbus support
+AC_ARG_ENABLE(dbus,
+ AS_HELP_STRING([--disable-dbus],
+ [do not build with dbus support]),,
+ enable_dbus=auto)
+if test "x$enable_dbus" != "xno"; then
+PKG_CHECK_MODULES(DBUS,
+ dbus-1 >= 1.6,
+ have_dbus=yes,
+ have_dbus=no)
+if test "x$have_dbus" = "xno" -a "x$enable_dbus" = "xyes"; then
+AC_MSG_ERROR([dbus support explicitly requested, but libdbus
couldn't be found])
+fi
+if test "x$have_dbus" = "xyes"; then
+enable_dbus=yes
+AC_DEFINE([HAVE_DBUS], [1], [Build with dbus support])
+else
+enable_dbus=no
+fi
+fi
+AM_CONDITIONAL(ENABLE_DBUS, test "x$enable_dbus" = "xyes")
+
AC_ARG_ENABLE(wcap-tools, [ --disable-wcap-tools],, enable_wcap_tools=yes)
AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
if test x$enable_wcap_tools = xyes; then
@@ -464,6 +486,7 @@ AC_MSG_RESULT([
EGL ${enable_egl}
libxkbcommon${enable_xkbcommon}
XWayland${enable_xwayland}
+ dbus${enable_dbus}
Build wcap utility ${enable_wcap_tools}
Build Tablet Shell ${enable_tablet_shell}
diff --git a/src/Makefile.am b/src/Makefile.am
index 2521b45..44ebfc2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -48,6 +48,14 @@ weston_SOURCES = \
weston-launch.h \
weston-egl-ext.h
+if ENABLE_DBUS
+weston_SOURCES += \
+ dbus.h \
+ dbus.c
+weston_CFLAGS += $(DBUS_CFLAGS)
+weston_LDADD += $(DBUS_LIBS)
+endif
+
git-version.h : .FORCE
$(AM_V_GEN)(echo "#define BUILD_ID \"$(shell git
--git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git
--git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')\"" > $@-new; \
cmp -s $@ $@-new || cp $@-new $@; \
diff --git a/src/dbus.c b/src/dbus.c
new file mode 100644
index 000..4de8c9c
--- /dev/null
+++ b/src/dbus.c
@@ -0,0 +1,336 @@
+/*
+ * Copyright © 2013 David Herrmann
+ *
+ * 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.
+ */
+
+/*
+ * DBus Helpers
+ * This file contain
[PATCH 3/7] Make weston spawn weston-launch
This is a rather complete rewrite of weston-launch. Instead of spawning
weston from weston-launch, we do the inverse now. Whenever weston is
spawned with a backend that uses launcher-util, we spawn weston-launch as
child process. weston-launch still handles VT switching and open() for
session-devices and passes them back to weston.
However, this drops all PAM, --user and session handling from
weston-launch. If we spawn weston-launch from weston, we cannot do any PAM
handling as it wouldn't affect weston, anymore. But this doesn't hurt as
the same effects can be achieved via "su", "sudo" or "/bin/login". There
is no real reason to do this in weston.
If you want weston to run in a new session, use one of these helpers to
create the session and then spawn weston from within the new session.
Some more differences are:
(1) We have now two sockets from weston to weston-launch. One for OPEN and
one for EVENTS. The reason for that is that if we send an OPEN request and
weston-launch schedules some VT-EVENT before sending the OPEN response,
launcher-util needs to handle the VT-EVENT from within
weston_launcher_open(). This isn't very hard to do, but may cause weird
side-effects as the callstack might already be an EVENT handling. There
are other ways to handle that, but the simplest way is to have two
independent queues.
(2) VT_ACTIVATE is privileged, so we pass the request to weston-launch
which then issues the VT_ACTIVATE ioctl.
(3) weston-launch is mandatory now. Every backend which uses launcher-util
requires weston-launch now. However, setuid is *not* mandatory! If
weston-launch does not have the setuid bit, you have to run weston as root
(as usual).
(4) Reading VTNR from systemd is now supported (requires systemd-207,
actually without the unreleased systemd-209 it will segfault due to a bug
in the implementation of sd_session_get_vt())
(5) I pass -v by default to weston-launch now. If someone doesn't like
that kind of verbosity, feel free to add a new command-line argument to
weston which forwards this flag.
---
configure.ac| 30 ++--
src/Makefile.am | 38 ++---
src/launcher-util.c | 430 ++--
src/weston-launch.c | 401 +---
src/weston-launch.h | 6 +
5 files changed, 386 insertions(+), 519 deletions(-)
diff --git a/configure.ac b/configure.ac
index 950086d..93a38ac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -53,7 +53,7 @@ AC_CHECK_DECL(CLOCK_MONOTONIC,[],
[[#include ]])
AC_CHECK_HEADERS([execinfo.h])
-AC_CHECK_FUNCS([mkostemp strchrnul initgroups])
+AC_CHECK_FUNCS([mkostemp strchrnul])
COMPOSITOR_MODULES="wayland-server >= 1.2.91 pixman-1"
@@ -316,21 +316,18 @@ AC_ARG_ENABLE(resize-optimization,
AS_IF([test "x$enable_resize_optimization" = "xyes"],
[AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as a
performance optimization])])
-AC_ARG_ENABLE(weston-launch, [ --enable-weston-launch],,
enable_weston_launch=yes)
-AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
-if test x$enable_weston_launch == xyes; then
- PKG_CHECK_MODULES(WESTON_LAUNCH, [libdrm])
- PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login],
- [have_systemd_login=yes], [have_systemd_login=no])
- AS_IF([test "x$have_systemd_login" = "xyes"],
- [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
-
- AC_CHECK_LIB([pam], [pam_open_session], [have_pam=yes], [have_pam=no])
- if test x$have_pam == xno; then
-AC_ERROR([weston-launch requires pam])
- fi
- WESTON_LAUNCH_LIBS="$WESTON_LAUNCH_LIBS -lpam"
-fi
+PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login],
+ [have_systemd_login=yes], [have_systemd_login=no])
+AS_IF([test "x$have_systemd_login" = "xyes"],
+ [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
+
+PKG_CHECK_MODULES(SYSTEMD_LOGIN_207, [libsystemd-login >= 207],
+ [have_systemd_login_207=yes], [have_systemd_login_207=no])
+AS_IF([test "x$have_systemd_login_207" = "xyes"],
+ [AC_DEFINE([HAVE_SYSTEMD_LOGIN_207], [1], [Have systemd-login >= 207])])
+
+PKG_CHECK_MODULES(LAUNCHER_UTIL, [libsystemd-login],,)
+PKG_CHECK_MODULES(WESTON_LAUNCH, [libdrm libsystemd-login],,)
if test x$enable_egl = xyes; then
PKG_CHECK_MODULES(GLU, [glu], [have_glu=yes], [have_glu=no])
@@ -471,7 +468,6 @@ AC_MSG_RESULT([
Build wcap utility ${enable_wcap_tools}
Build Tablet Shell ${enable_tablet_shell}
- weston-launch utility ${enable_weston_launch}
weston-launch systemd support ${have_systemd_login}
DRM Compositor ${enable_drm_compositor}
diff --git a/src/Makefile.am b/src/Makefile.am
index b0eae7c..2521b45 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,5 +1,4 @@
-bin_PROGRAMS = weston \
- $(weston_launch)
+bin_PROGRAMS = weston
AM_CPPFLAGS
[PATCH 2/7] fbdev: open launcher only once
We currently call launcher_connect() twice, which is redundant and
amazingly works (ugh?). Fix this and connect only once to the launcher.
---
src/compositor-fbdev.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 002ce0b..4376345 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -883,15 +883,6 @@ fbdev_compositor_create(struct wl_display *display, int
*argc, char *argv[],
config) < 0)
goto out_free;
- /* Check if we run fbdev-backend using weston-launch */
- compositor->base.launcher =
- weston_launcher_connect(&compositor->base, param->tty);
- if (compositor->base.launcher == NULL && geteuid() != 0) {
- weston_log("fatal: fbdev backend should be run "
- "using weston-launch binary or as root\n");
- goto out_compositor;
- }
-
compositor->udev = udev_new();
if (compositor->udev == NULL) {
weston_log("Failed to initialize udev context.\n");
@@ -905,7 +896,8 @@ fbdev_compositor_create(struct wl_display *display, int
*argc, char *argv[],
compositor->base.launcher =
weston_launcher_connect(&compositor->base, param->tty);
if (!compositor->base.launcher) {
- weston_log("Failed to set up launcher.\n");
+ weston_log("fatal: fbdev backend should be run "
+ "using weston-launch binary or as root\n");
goto out_udev;
}
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/7] evdev: release devices on read() error
If read() fails without EAGAIN/EINTR, the device is very likely dead.
However, we must not remove the device as it might be muted/revoked. So we
simply remove the event-source to avoid polling the device and simply wait
for the udev-remove signal now.
Note that we cannot call evdev_device_destroy() as the caller created the
FD and might need custom code to close it (like weston_launcher_close()).
---
src/evdev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index edea396..7397ea1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -22,6 +22,7 @@
#include "config.h"
+#include
#include
#include
#include
@@ -414,7 +415,13 @@ evdev_device_data(int fd, uint32_t mask, void *data)
len = read(fd, &ev, sizeof ev);
if (len < 0 || len % sizeof ev[0] != 0) {
- /* FIXME: call evdev_device_destroy when errno is
ENODEV. */
+ if (len < 0 && errno != EAGAIN && errno != EINTR) {
+ weston_log("device %s died\n",
+ device->devnode);
+ wl_event_source_remove(device->source);
+ device->source = NULL;
+ }
+
return 1;
}
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] Use an integer type for modifiers bit mask.
Hi On Fri, Oct 4, 2013 at 2:34 PM, Daniel Stone wrote: > On 4 October 2013 13:09, Wander Lairson Costa > wrote: >> That's what the patch is about: avoid casts. Whenever you use a cast, >> you are giving up the help the compiler may give to you regarding >> invalid type conversions. So, I always use the rule of thumb of >> avoiding casts whenever I can. IMO, this is not a harmful patch and >> will make the C++ programmers a little bit easier. > > I can see where it's going, but on the other hand xkb_mod_mask_t is > _so_ not the right type. That's a bitmask of actual modifiers (i.e. > the return value), not a bitmask of components. So it avoids the > cast, but also makes the API look extremely misleading, as we've > documented exactly what xkb_mod_mask_t is. > > I really like the type safety aspect, so to be honest I'm just > inclined to make C++ wear the cast for now. We had a similar discussion when I pointed out that "enum" may change the underlying type without notice when adding new enum-values. But I agree with Daniel, the GCC type-safety for enums in C is a very handy feature. So I'm also no big fan of the patch, sorry. Thanks David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC DRAFT] graphics tablet protocol extension
Hi Peter
On Wed, Oct 2, 2013 at 11:13 PM, Peter Hutterer
wrote:
> On Wed, Oct 02, 2013 at 05:44:29PM +0200, David Herrmann wrote:
>> Hi Peter
>>
>> On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
>> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> > index aeb0412..8d10746 100644
>> > --- a/protocol/wayland.xml
>> > +++ b/protocol/wayland.xml
>> > @@ -1235,7 +1235,7 @@
>> >
>> >
>> >
>> > -
>> > +
>> >
>> >A seat is a group of keyboards, pointer and touch devices. This
>> >object is published as a global during start up, or when such a
>> > @@ -1251,6 +1251,7 @@
>> >
>> >
>> >
>> > +
>>
>> What's actually the reason to allow multiple graphics-tablets per
>> seat? I thought wl_seat objects respresent a single user interacting
>> with your desktop. So if you have two tablets, why not force them to
>> be in two different wl_seat objects? Is there ever a reason to have
>> multiple tablets in a single seat? What would the use-case be?
>
> my laptop has a built-in wacom tablet (lenovo x220t), but I also have an
> Intuos4 plugged in. depending on the use-case I use either, but they should
> be in the same seat. two wl_seat objects means two different keyboard foci
> (only one of which actually works if you have only one keyboard), etc.
> I also know of professional setups that require two tablets or more.
>
> ideally there'd be just one generic wl_tablet per seat, same as wl_pointer
> but the tablets differ too much to make that useable. Hence the multiple
> wl_tablet objects.
Yepp, merging them might be not as easy as with keyboards/mice. Point taken.
>> We could even go further and put tablets into their own seats. Always.
>> A pointer and keyboard may be used by a single user at the same time.
>> But for a graphics-tablet that doesn't sound like a legitimate
>> use-case, does it? But maybe I just have a different view of wl_seat..
>> don't know. I somehow have the feeling we never really agreed on how
>> to define wl_seat objects. Currently they are just user-defined groups
>> of devices with some specific policies ("only one keyboard-object per
>> seat").
>
> my understanding of wl_seat is "one group of input devices". that would
> usually map to one user. it's already not ideal for the bimanual input but
> then again that's even more of a corner case than multiple seats.
>
> once you start moving devices out into other seats, you're in trouble. a
> seat defines keyboard events, so anything that has an interaction with the
> keyboard can't easily be unpaired. a tablet is a fancy pointer device,
> users expect to click somewhere and have it work as a mouse, i.e.
> to move the keyboard focus to wherever you just clicked.
> moving it into a different seat means you'd have to switch to a mouse to
> change the keyboard focus. or, if you have two wl_seats you now need to pair
> them somehow to have the right focus behaviour. and that is going to be
> horrible.
Ok, so wl_seat is just about input focus. I had a much stricter view
of it but obviously it makes it hard to control focus of seats without
mice/keyboards. So yeah, agreed.
>> >
>> >
>> >
>> > @@ -1306,6 +1307,19 @@
>> >
>> >
>> >
>> > +
>> > +
>> > +
>> > +The ID provided will be initialized to the wl_tablet_manager
>> > +interface for this seat. This can then be used to retrieve the
>> > +objects representing the actual tablet devices.
>> > +
>> > +This request only takes effect if the seat has the tablets
>> > +capability.
>> > +
>> > +
>> > +
>> > +
>> >
>> >
>> >
>> > @@ -1617,6 +1631,223 @@
>> >
>> >
>> >
>> > +
>> > +
>> > + A tablet manager object provides requests to access the graphics
>> > + tablets available on this system.
>> > +
>> > +
>> > +
>> > +
>> > +Describes the type of tablet.
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>> > +
>>
>> So tablets are serv
Re: [RFC DRAFT] graphics tablet protocol extension
Hi Peter
On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
wrote:
> I've been working on a protocol extension to support graphics tablets such
> as the Wacom set of tablets, and I'm now at the stage where I'd like a few
> comments. I was hoping that I'd get a full implementation before XDC but
> unfortunately that didn't happen, so for now I'll just show the protocol.
> I've got a PoC implementation, but it's missing a few too many pieces to be
> actually usable just yet.
>
> Any feedback appreciated. This is a relatively early stage, so there are
> still many changes expected.
>
> The goal is to make it possible to access graphics tablets. One important
> thing to note is that this interface does _not_ cover the touch ability of
> some tablets. This should go through wl_touch (for touchscreen-like tablets)
> or wl_pointer (for external touchpad-like tablets).
>
> There are a few notable differences to the wl_pointer interface:
> * tablets have a tool type that matters, it lets applications such as the
> GIMP select paint tools based on the physical tool. those tools also often
> have HW serial numbers to uniquely identify them.
> * extra axes mattter: pressure, tilt, distance - all influence the stylus
> behaviour
> * more than one device may be present, so it's important to have access to
> all devices on a one-by-one basis. unlike wl_pointer, where we just have
> one virtual pointer.
> * proximity matters since we can leave proximity from directly above a
> surface. the pointer can't do that, it moves from one surface to the next.
> so in some ways it's closer to wl_touch in that regard.
>
> Some design notes:
> * generally most axes change at the same time, hence the choice to send a
> wl_array instead of separate events.
> * x/y would have to be adjusted relative to the surface, but technically the
> same would have to be done to e.g. distance on a true 3D desktop.
> * not sure at all about the relative events at all or if there's a need for
> it. iirc only some styly have REL_*WHEEL, do we need something else? Ping,
> Jason?
> * I don't have a specific touch event, I figured BTN_TOUCH would do the job.
> * focus handling for the stylus is easy. focus handling for the buttons on
> the pad isn't. they could technically be focused elsewhere, like a
> keyboard focus. some buttons are definitely stylus based (BTN_STYLUS,
> BTN_STYLUS2, etc.) so should go where the stylus is. Should look at what
> Win/OSX do here.
> * bind/binding/unbind - this is like windowed mode in GIMP. do we still need
> this? who's actually using this instead of a full-screen app?
> * tablet_manager is a bit meh, but the only alternative would be to have a
> wl_seat::get_tablets request and a wl_seat::tablet_added event. Possible,
> but doesn't look that much nicer. but it does away with the indirection.
> (read the diff below to understand what I mean here)
> * if we stick with the tablet_manager, do we need a
> wl_tablet_manager::get_tablets request in case the client releases a
> tablet it needs again later? or do we expect to re-bind to
> wl_tablet_manager?
> * fuzz/flat should be dropped, I just haven't yet.
> * I'd really like to enscribe in the protocol that ABS_PRESSURE means just
> that and damn anyone else who wants to use 0x18 as axis code. weston
> does this for wl_pointer::button, but it's not actually documented. what's
> the deal here?
> * does this even make sense as wl_tablet or should I try first as
> experimental weston-tablet interface that then (maybe) moves later to
> wayland proper.
>
> That's it so far, again, any feedback appreciated. diff below.
>
> Cheers,
>Peter
>
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index aeb0412..8d10746 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1235,7 +1235,7 @@
>
>
>
> -
> +
>
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1251,6 +1251,7 @@
>
>
>
> +
What's actually the reason to allow multiple graphics-tablets per
seat? I thought wl_seat objects respresent a single user interacting
with your desktop. So if you have two tablets, why not force them to
be in two different wl_seat objects? Is there ever a reason to have
multiple tablets in a single seat? What would the use-case be?
We could even go further and put tablets into their own seats. Always.
A pointer and keyboard may be used by a single user at the same time.
But for a graphics-tablet that doesn't sound like a legitimate
use-case, does it? But maybe I just have a different view of wl_seat..
don't know. I somehow have the feeling we never really agreed on how
to define wl_seat objects. Currently they are just user-defined groups
of devices with some specific policies ("only one keyboard-object per
seat").
>
>
>
> @@ -1306,6 +1307,19 @@
>
>
Re: [RFC wayland] System compositor protocol
Hi On Tue, Aug 27, 2013 at 9:16 PM, microcai wrote: > 2013/8/25 David Herrmann : [...] >> The idea behind a system-compositor was to provide a system daemon >> that runs _outside_ a session. Its sole responsibility is to control >> access to graphics and input hardware. So session-compositors no >> longer access hardware directly, but instead tunnel it through the >> system-compositor. But this means, the system-compositor must know of >> session-switches and correctly display only the session-compositor of >> the active session. However, session-switching is controlled by >> logind, so the system-compositor gets the session-switch notification >> _after_ the session was actually switched, making this kind of racy >> (but still ok!). > > when the user wants to switch, logind should be notified by system-compositor. > system-compositer controls the screen and the input, not logind, so > there should be no race. Yeah, this is *not* how it works. Currently a session-switch is controlled by either the kernel (for VTs) or by logind. I don't see any reason why this should change. Please explain yourself if you disagree. >> The bigger problem is, the system-compositor is not part of a session >> so it has to be active *all the time*. You cannot have some sessions >> using the system-compositor and other sessions doing it the old way. >> You cannot do device-access handover from the system-compositor to a >> self-hosting or legacy session. This would require ugly racy hacks and >> conflict with VT! >> But if the system-compositor is always active, you cannot use VTs in >> text-mode. Because VTs in text-mode access graphics hardware >> *directly*. > > if we want to kill VT, then better we have system-compositor. I see no reason > to support kernel VTs when you could have system-compositor. I don't see any reason to support VTs at all. But it's not me to decide, so we will always support VTs for backwards compatibility. > system-compositor is not always active. In fact, it only got wake up when you > do session switch. the session compositor directly render to the screen. there > is no need to wake up system-compositor here. In this scenario, how does the system-compositor know whether the session that you switch to renders directly or requires the system-compositor? > sessions that does not use system-compositor is a dead end. > All sessions should and must output to system-compositor. > system-compositor should be socket activated, and guaranteed to be there. Please elaborate. You are just claiming stuff without explaining why.. Or is this just your opinion? [...] >> >> Yepp, that's all we need. Just rename it from "system_compositor" to >> "wl_fullscreen_shell" (I bet you can come up with some fancier name). >> No other criticism on this proposal from my side. >> >> Feel free to disagree ;) I am open for suggestions or criticism. >> Cheers >> David > > > with system-compositor, we can do cross-session visual effects > that's hard to be done without a system-compositor. And "hard to be done" is bad? Choosing the convenient way here means adding latency (by routing everything through the system-compositor). We don't want that. And "cross-session visual effects" are still possible. I will present that at XDC in 1 month. > with system-compositor, we provide unified input handing, > multi-GPU handing, multi-monitor handing, and integrate that well with logind. Please show to me how this integrates well with logind? "Multi-GPU", "multi-monitor", "unified input",.. that has nothing to do with a system-compositor. You can have that with session-compositors, too. In fact, we already have all that.. > with system-compositor, we killed kernel VTs. we can still provide > text terminal as clients of system-compositor. Has nothing to do with system-compositors.. > with system-compositor, we secured our GPUs. What? In your claim above you said system-compositors *don't* always have to be active. How do you protect your GPU during such switches? > with system-compositor, we can make system-compositor to load old Xorg drivers > to bring up OGL and do user-mode setting while native KMS drivers absent. Again, this has nothing to do with system-compositors. You can implement that in any compositor. Regards David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [systemd-devel] [PATCH 00/10] Device Management for systemd-logind
Hi On Mon, Aug 26, 2013 at 6:37 AM, Tom Gundersen wrote: > On Sun, Aug 25, 2013 at 8:46 PM, David Herrmann wrote: >> logind itselfs takes care of revoking device access for inactive sessions >> (synchronized with session-switches!). It also tries to resume every device >> when a session is activated. But session-devices must not be used to watch >> session state! A compositor has to use the PropertiesChanged() signal plus >> the >> "Active" property of sessions for that! Session-devices do not replace this! >> On >> sessions with VTs, this is obviously replaced by the VT_SETMODE interface as >> usual. > > So essentially, all clients have to keep implementing the old > VT_SETMODE interface in addition to the new logind one? > > Would it be possible to ship a wrapper around VT_SETMODE and friends > so that new clients could only implement the logind interface, and > logind would deal with the VT layer internally (or rather, I suppose, > via some shim session daemon) when necessary? It's an orthogonal problem. And you don't need to handle it at all. The default for VT_SETMODE is a forced VT switch. So as long as no process in a session opens the VT and modifies VT_SETMODE, VT switch will "Just Work". And logind is notified via /sys/class/tty/tty0/active Thanks for looking over it, btw! David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] System compositor protocol
Hi On Mon, Aug 26, 2013 at 10:48 AM, Cedric BAIL wrote: > Hello, > > Cedric Bail > > > On Aug 26, 2013 2:11 AM, "David Herrmann" wrote: >> >> Hi >> >> On Fri, Aug 23, 2013 at 11:55 PM, Jason Ekstrand >> wrote: >> > Hello All, >> > I am in the process of picking back up the old idea of system >> > compositors. >> > I am not, at the moment, looking for a review of the code; simply a >> > review >> > of the concept and the proposed protocol. If you would like to look at >> > my >> > implementation or try it out, it can be found in the system-compositor >> > branch of my personal [weston fork on github][1]. >> > >> > What follows is what I envision for system compositors. (Others may have >> > a >> > different idea which is why I'm writing this RFC email.) The basic idea >> > behind a system compositor is to provide an interface for compositors >> > whose >> > only job it is to display other compositors or other stand-alone >> > full-screen interfaces. I image three primary purposes for system >> > compositors: >> > >> > 1. As an abstraction layer. Every time someone wants to write a RDP >> >server, VNC server, android backend, or the like the standard answer >> > is >> >"write it as a weston plugin". The problem with this is that, to my >> >knowledge, none of the major desktop environments (GNOME, KDE, EFL, >> >etc.) plan to run their compositor as a weston shell plugin. This >> > makes >> >a weston plugin a poor solution in the long term. On the other hand, >> > a >> >system compositor is fairly simple to implement and provides a >> > backend >> >to any compositor that can run on top of a system compositor. >> >> KDE planned on using weston as underlying compositor. But I doubt >> GNOME or EFL want to use something like that.. > > Indeed, Enlightenment is not planning to use Weston. But if a common library > dealing with all those drm / kms, android, rpi,... did exist, I am sure we > would use it and contribute to it. I am not a big fan of adding a system > compositor as it will impact speed and power consumption. As long as we can > avoid it, and work on systemd / logind seems to go this way, I think it > would be better. I did try this with kmscon, but I never moved the library out of the kmscon-repo as it is a quite fast moving target. So it will probably take a while until we figure out some proper API. And interest seems pretty low.. [...] >> So back to your proposal. I'd like to see something like you did but >> as a session-compositor (call it whatever you want ;)). So a session >> that doesn't want to deal with DRM directly (like for instance >> gdm/xdm/kdm) could avoid starting an xserver or weston and start your >> session-compositor instead. It then displays it's content via the >> standard wayland client APIs on this compositor. But this compositor >> imho should run in a session. So it does *not* allow clients from >> different sessions to connect. It is *no* system compositor. It's just >> a daemon which provides graphics-access to the session. It may even >> allow switching between multiple surfaces. And if you continue this >> thought, you will notice that it is nothing more than weston but with >> a *very* reduced wl_shell. Precisely a wl_shell that displays only one >> surface at a time. > > What would be the benefit over a library that does the job in the > compositor/single application ? A library would work as long as you have only a single client. But imagine your login-session also wants a screensaver. You could make this compositor support a shell which allows a full-screen client (login-screen) and additionally a screen-saver client. So as long as your wl_whatever_shell in this compositor is limited to a single client, I agree, a library would be better. But if you make it just a little more complex, you should rather use a compositor. Regards David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 10/10] logind: implement generic multi-session
Hi On Sun, Aug 25, 2013 at 5:17 PM, Tom Gundersen wrote: > Hi David, > > On Sun, Aug 25, 2013 at 8:46 PM, David Herrmann wrote: >> One important note is that delayed session-switching is meant for >> backwards compatibility. New compositors or other sessions should really >> try to deal correctly with forced session switches! They only need to >> handle EACCES/EPERM from syscalls and treat them as "PauseDevice" signal. >> >> Following logind patches will add a timeout to session-switches which >> forces the switch if the active session does not react in a timely >> fashion. Moreover, explicit ForceActivate() calls might also be supported. >> Hence, sessions must not crash if their devices get paused. [...] > Do you have reason to believe that handling EACCESS would be > significantly harder than just porting to the PauseDevice interface? [...] Yes. For the XServer device handling is done in drivers. There are many of xf86-video-* drivers and I have no intention to fix all of them. Note that device-enumeration (udev etc) is done in the xserver core. This could be fixed more easily. But as said in the introduction-text, this is *only* for compatibility. And the longer I think about it, I get more and more convinced to drop it all-together. It's handy to test it and play around with it, but maybe the final revision would be better off without it. If anyone wants to run an xserver with it, they ought to use a driver that can deal with asynchronous session-switches. Cheers David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] System compositor protocol
Hi On Fri, Aug 23, 2013 at 11:55 PM, Jason Ekstrand wrote: > Hello All, > I am in the process of picking back up the old idea of system compositors. > I am not, at the moment, looking for a review of the code; simply a review > of the concept and the proposed protocol. If you would like to look at my > implementation or try it out, it can be found in the system-compositor > branch of my personal [weston fork on github][1]. > > What follows is what I envision for system compositors. (Others may have a > different idea which is why I'm writing this RFC email.) The basic idea > behind a system compositor is to provide an interface for compositors whose > only job it is to display other compositors or other stand-alone > full-screen interfaces. I image three primary purposes for system > compositors: > > 1. As an abstraction layer. Every time someone wants to write a RDP >server, VNC server, android backend, or the like the standard answer is >"write it as a weston plugin". The problem with this is that, to my >knowledge, none of the major desktop environments (GNOME, KDE, EFL, >etc.) plan to run their compositor as a weston shell plugin. This makes >a weston plugin a poor solution in the long term. On the other hand, a >system compositor is fairly simple to implement and provides a backend >to any compositor that can run on top of a system compositor. KDE planned on using weston as underlying compositor. But I doubt GNOME or EFL want to use something like that.. > 2. Simple full-screen clients. With standard VTs going the way of the dodo >bird (see also [David Herrmann's work on logind][2]), we will need a way >for displaying simple full-screen programs such as splashscreens without >every single one of them knowing how to talk DRM/KMS directly. David >has proposed to use a system compositor (which he calls wlsystemc in his >post) so these types of programs can be written as simple wayland >clients. My github repository contains the (almost trivial) >modifications to simple-shm that make it in to one such client. Yay, I appreciate someone picking up this idea \o/ > 3. As a DRM/KMS backend for other compositors. Manually dealing with >DRM/KMS isn't actually all that many lines and all of the big >compositors (mutter, Kwin, EFL, etc.) will do it themselves. However, >for people who want to write their own simple compositor, it can be a >bit tricky to get right and raises the barrier to entry. The protocol >I'm proposing is sufficiently powerful to provide most of the basic >multi-output support and modesetting that is needed for a simple >compositor. This means that all a potential compositor writer has to do >is write a system compositor client and they can let someone else get >the KMS details right. Manually dealing with DRM/KMS _is_ hard. Yes, the basic setup is easy, but I hate the fact that we now end up with everyone doing it on their own. Advanced things can get pretty complex, like GPU selection, multi-GPU handling, GPU hotplugging, CRTC hotplugging, planes, cursors, DRM-Master, DPMS, DRM properties, atomic modesetting, render-nodes, .. ugh, this list can get soo long. I am a little bit scared that EFL or Gnome get it wrong, but ok, not my deal. > While it sounds like a big task, implementing a system compositor isn't > that bad. The simplest system compositor is one that can simply display > surfaces. In order to do that, you need to implement the following > interfaces: > > * wl_compositor > * wl_region > * wl_shm (along with wl_shm_pool and a SHM-based wl_buffer) > * wl_surface > * wl_output > > None of those are particularly difficult or complicated to implement. The > hardest is probably wl_surface and that's not terrible. > > For input you have two options. The first, most obvious option is to > implement wl_seat and its child interfaces. Second, I have considered the > idea of a wl_raw_input interface (only for system compositors) that simply > provides evdev file descriptors to the client. This would allow for raw > input processing without having to worry about things like weston-launch. > Also the system compositor *may* be able to handle the FD muting etc. for > playing nice with logind. (I'm not sure on that one yet, I'd have to ask > David.) > > One more note on input: I do NOT expect the system compositor to do any > significant input processing. Even if the child compositor is getting its > events through wl_seat, I expect them to be about as raw as possible. In > particular, this is not where things like pointer acceleration should be > handled. Once we get a pointer_grab interface working, I expect any > compositor that runs on top of a system compositor to attempt a pointer > grab almost immediately and do its own pointer handling from there. > Otherwise it is impossible for the client compositor to re-arrange the > outputs without additional protocol. > > Alo
Re: [PATCH wayland-web] building: Recommend disabling setuid for non-root installs
Hi On Sun, Aug 25, 2013 at 9:57 AM, Pekka Paalanen wrote: > On Fri, 23 Aug 2013 19:54:17 + > "Bryce W. Harrington" wrote: > >> The build directions guide the user to build and install Wayland in a >> user directory without using superuser privs. However, the weston build >> process includes a `chown root` on weston-launcher done by default, >> which results in a failed build when running make install as >> non-superuser, unless we pass --enable-setuid-install=no to disable the >> feature. >> >> (Probably would be better to fix weston so make install works as >> non-root, but for now just document the workaround...) >> >> Signed-off-by: Bryce Harrington >> --- >> building.html |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/building.html b/building.html >> index b7a1158..a47744e 100644 >> --- a/building.html >> +++ b/building.html >> @@ -228,7 +228,7 @@ gio-2.0. >> >> $ git clone git://anongit.freedesktop.org/wayland/weston >> $ cd weston >> -$ ./autogen.sh --prefix=$WLD >> +$ ./autogen.sh --prefix=$WLD --enable-setuid-install=no >> $ make >> $ make install >> > > I believe setuid weston-launch is mandatory for all backends > that use evdev, that is at least drm and fbdev. Otherwise they > cannot open input devices on normal system setups. > > Maybe prefer 'sudo make install' then? It is also mandatory for DRM (see drmSetMaster()). So I'd recommend "sudo", too. Cheers David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 10/10] logind: implement generic multi-session
This enables the multi-session capability for seats that don't have VTs.
For legacy seats with VTs, everything stays the same. However, all other
seats now also get the multi-session capability.
The only feature that was missing was session-switching. As logind can
force a session-switch and signal that via the "Active" property, we only
need a way to allow synchronized/delayed session switches. Compositors
need to cleanup some devices before acknowledging the session switch.
Therefore, we use the session-devices to give compositors a chance to
block a session-switch until they cleaned everything up.
If you activate a session on a seat without VTs, we send a PauseDevice
signal to the active session for every active device. Only once the
session acknowledged all these with a PauseDeviceComplete() call, we
perform the final session switch.
One important note is that delayed session-switching is meant for
backwards compatibility. New compositors or other sessions should really
try to deal correctly with forced session switches! They only need to
handle EACCES/EPERM from syscalls and treat them as "PauseDevice" signal.
Following logind patches will add a timeout to session-switches which
forces the switch if the active session does not react in a timely
fashion. Moreover, explicit ForceActivate() calls might also be supported.
Hence, sessions must not crash if their devices get paused.
---
src/login/logind-seat.c | 15 +++
src/login/logind-seat.h | 2 ++
src/login/logind-session-device.c | 28
src/login/logind-session-device.h | 1 +
src/login/logind-session.c| 31 ++-
5 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index f88738a..4a4d40a 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -425,6 +425,21 @@ int seat_attach_session(Seat *s, Session *session) {
return 0;
}
+void seat_complete_switch(Seat *s) {
+Session *session;
+
+assert(s);
+
+/* if no session-switch is pending or if it got canceled, do nothing */
+if (!s->pending_switch)
+return;
+
+session = s->pending_switch;
+s->pending_switch = NULL;
+
+seat_set_active(s, session);
+}
+
bool seat_has_vts(Seat *s) {
assert(s);
diff --git a/src/login/logind-seat.h b/src/login/logind-seat.h
index d3438b8..be6db6e 100644
--- a/src/login/logind-seat.h
+++ b/src/login/logind-seat.h
@@ -38,6 +38,7 @@ struct Seat {
LIST_HEAD(Device, devices);
Session *active;
+Session *pending_switch;
LIST_HEAD(Session, sessions);
bool in_gc_queue:1;
@@ -59,6 +60,7 @@ int seat_read_active_vt(Seat *s);
int seat_preallocate_vts(Seat *s);
int seat_attach_session(Seat *s, Session *session);
+void seat_complete_switch(Seat *s);
bool seat_has_vts(Seat *s);
bool seat_is_seat0(Seat *s);
diff --git a/src/login/logind-session-device.c
b/src/login/logind-session-device.c
index 7c6b07f..7123955 100644
--- a/src/login/logind-session-device.c
+++ b/src/login/logind-session-device.c
@@ -452,10 +452,21 @@ void session_device_free(SessionDevice *sd) {
}
void session_device_complete_pause(SessionDevice *sd) {
+SessionDevice *iter;
+Iterator i;
+
if (!sd->active)
return;
session_device_stop(sd);
+
+/* if not all devices are paused, wait for further completion events */
+HASHMAP_FOREACH(iter, sd->session->devices, i)
+if (iter->active)
+return;
+
+/* complete any pending session switch */
+seat_complete_switch(sd->session->seat);
}
void session_device_resume_all(Session *s) {
@@ -487,3 +498,20 @@ void session_device_pause_all(Session *s) {
}
}
}
+
+unsigned int session_device_try_pause_all(Session *s) {
+SessionDevice *sd;
+Iterator i;
+unsigned int num_pending = 0;
+
+assert(s);
+
+HASHMAP_FOREACH(sd, s->devices, i) {
+if (sd->active) {
+session_device_notify(sd, SESSION_DEVICE_TRY_PAUSE);
+++num_pending;
+}
+}
+
+return num_pending;
+}
diff --git a/src/login/logind-session-device.h
b/src/login/logind-session-device.h
index 98e61e6..61732bc 100644
--- a/src/login/logind-session-device.h
+++ b/src/login/logind-session-device.h
@@ -55,3 +55,4 @@ void session_device_complete_pause(SessionDevice *sd);
void session_device_resume_all(Session *s);
void session_device_pause_all(Session *s);
+unsigned int session_device_try_pause_all(Session *s);
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index e7fe0f6..61366c1 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -99,6 +99,8 @@ void session_free(Session *s) {
if (s->seat
[PATCH 09/10] logind: extract has_vts() from can_multi_session()
We currently use seat_can_multi_session() to test for two things:
* whether the seat can handle session-switching
* whether the seat has VTs
As both are currently logically equivalent, we didn't care. However, we
want to allow session-switching on seats without VTs, so split this helper
into:
* seat_can_multi_session(): whether session-switching is supported
* seat_has_vts(): whether the seat has VTs
Note that only one seat on a system can have VTs. There is only one set of
them. We automatically assign them to seat0 as usual.
With this patch in place, we can easily add new session-switching/tracking
methods without breaking any VT code as it is now protected by has_vts(),
no longer by can_multi_session().
---
src/login/logind-dbus.c| 2 +-
src/login/logind-seat.c| 32 ++--
src/login/logind-seat.h| 1 +
src/login/logind-session.c | 6 +++---
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 8940aeb..5e42c0a 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -429,7 +429,7 @@ static int bus_manager_create_session(Manager *m,
DBusMessage *message) {
}
if (seat) {
-if (seat_can_multi_session(seat)) {
+if (seat_has_vts(seat)) {
if (vtnr > 63)
return -EINVAL;
} else {
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index 4c2c424..f88738a 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -201,7 +201,7 @@ int seat_preallocate_vts(Seat *s) {
if (s->manager->n_autovts <= 0)
return 0;
-if (!seat_can_multi_session(s))
+if (!seat_has_vts(s))
return 0;
for (i = 1; i <= s->manager->n_autovts; i++) {
@@ -282,7 +282,7 @@ int seat_active_vt_changed(Seat *s, int vtnr) {
assert(s);
assert(vtnr >= 1);
-if (!seat_can_multi_session(s))
+if (!seat_has_vts(s))
return -EINVAL;
log_debug("VT changed to %i", vtnr);
@@ -306,7 +306,7 @@ int seat_read_active_vt(Seat *s) {
assert(s);
-if (!seat_can_multi_session(s))
+if (!seat_has_vts(s))
return 0;
lseek(s->manager->console_active_fd, SEEK_SET, 0);
@@ -417,18 +417,20 @@ int seat_attach_session(Seat *s, Session *session) {
seat_send_changed(s, "Sessions\0");
-/* Note that even if a seat is not multi-session capable it
- * still might have multiple sessions on it since old, dead
- * sessions might continue to be tracked until all their
- * processes are gone. The most recently added session
- * (i.e. the first in s->sessions) is the one that matters. */
-
-if (!seat_can_multi_session(s))
+/* On seats with VTs, the VT logic defines which session is active. On
+ * seats without VTs, we automatically activate the first session. */
+if (!seat_has_vts(s) && !s->active)
seat_set_active(s, session);
return 0;
}
+bool seat_has_vts(Seat *s) {
+assert(s);
+
+return seat_is_seat0(s) && s->manager->console_active_fd >= 0;
+}
+
bool seat_is_seat0(Seat *s) {
assert(s);
@@ -438,19 +440,13 @@ bool seat_is_seat0(Seat *s) {
bool seat_can_multi_session(Seat *s) {
assert(s);
-if (!seat_is_seat0(s))
-return false;
-
-/* If we can't watch which VT is in the foreground, we don't
- * support VT switching */
-
-return s->manager->console_active_fd >= 0;
+return seat_has_vts(s);
}
bool seat_can_tty(Seat *s) {
assert(s);
-return seat_is_seat0(s) && s->manager->console_active_fd >= 0;
+return seat_has_vts(s);
}
bool seat_has_master_device(Seat *s) {
diff --git a/src/login/logind-seat.h b/src/login/logind-seat.h
index 47fe89a..d3438b8 100644
--- a/src/login/logind-seat.h
+++ b/src/login/logind-seat.h
@@ -60,6 +60,7 @@ int seat_preallocate_vts(Seat *s);
int seat_attach_session(Seat *s, Session *session);
+bool seat_has_vts(Seat *s);
bool seat_is_seat0(Seat *s);
bool seat_can_multi_session(Seat *s);
bool seat_can_tty(Seat *s);
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index 50ba6b8..e7fe0f6 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -205,7 +205,7 @@ int session_save(Session *s) {
if (s->service)
fprintf(f, "SERVICE=%s\n", s->service);
-if (s->seat && seat_can_multi_session(s->seat))
+if (s->seat && seat_has_vts(s->seat))
fprintf(f, "VTNR=%i\n", s->vtnr);
if (s->leader > 0)
@@ -315,7 +315,7 @@ int session_load(Session *s) {
seat_attach_session(o, s);
}
-if (vtnr && s->seat && seat_can_multi_session(s->seat)) {
[PATCH 08/10] logind: fix session_activate(vtnr = 0)
VT numbers start with 1. If a session has vtnr == 0, we must not assume it
is running on a VT.
Note that this could trigger the assert() below as CreateSession() sets
vtnr to 0, not <0.
---
src/login/logind-session.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index ae91650..50ba6b8 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -377,7 +377,7 @@ int session_activate(Session *s) {
assert(s);
assert(s->user);
-if (s->vtnr < 0)
+if (s->vtnr <= 0)
return -ENOTSUP;
if (!s->seat)
--
1.8.3.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 07/10] logind: fix seat_can_tty() to check for VTs
A seat provides text-logins if it has VTs. This is always limited to seat0
so the seat_is_seat0() check is correct. However, if VTs are disabled, no
seat provides text-logins so we also need to check for the console-fd.
This was previously:
return seat_is_vtconsole();
It looked right, but was functionally equivalent to seat_is_seat0(). The
rename of this helper made it more obvious that it is missing the VT test.
---
src/login/logind-seat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index 88fd724..4c2c424 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -450,7 +450,7 @@ bool seat_can_multi_session(Seat *s) {
bool seat_can_tty(Seat *s) {
assert(s);
-return seat_is_seat0(s);
+return seat_is_seat0(s) && s->manager->console_active_fd >= 0;
}
bool seat_has_master_device(Seat *s) {
--
1.8.3.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 06/10] logind: rename vtconsole to seat0
The seat->vtconsole member always points to the default seat seat0. Even
if VTs are disabled, it's used as default seat. Therefore, rename it to
seat0 to correctly state what it is.
This also changes the seat files in /run from IS_VTCONSOLE to IS_SEAT0. It
wasn't used by any code, yet, so this seems fine.
While we are at it, we also remove every "if (s->vtconsole)" as this
pointer is always valid!
---
src/login/logind-dbus.c| 8
src/login/logind-seat.c| 14 +++---
src/login/logind-seat.h| 2 +-
src/login/logind-session.c | 2 +-
src/login/logind.c | 8
src/login/logind.h | 2 +-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index a703e59..8940aeb 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -404,8 +404,8 @@ static int bus_manager_create_session(Manager *m,
DBusMessage *message) {
int v;
if (!seat)
-seat = m->vtconsole;
-else if (seat != m->vtconsole)
+seat = m->seat0;
+else if (seat != m->seat0)
return -EINVAL;
v = vtnr_from_tty(tty);
@@ -420,8 +420,8 @@ static int bus_manager_create_session(Manager *m,
DBusMessage *message) {
} else if (tty_is_console(tty)) {
if (!seat)
-seat = m->vtconsole;
-else if (seat != m->vtconsole)
+seat = m->seat0;
+else if (seat != m->seat0)
return -EINVAL;
if (vtnr != 0)
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index dcaf0ac..88fd724 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -105,11 +105,11 @@ int seat_save(Seat *s) {
fprintf(f,
"# This is private data. Do not parse.\n"
-"IS_VTCONSOLE=%i\n"
+"IS_SEAT0=%i\n"
"CAN_MULTI_SESSION=%i\n"
"CAN_TTY=%i\n"
"CAN_GRAPHICAL=%i\n",
-seat_is_vtconsole(s),
+seat_is_seat0(s),
seat_can_multi_session(s),
seat_can_tty(s),
seat_can_graphical(s));
@@ -429,16 +429,16 @@ int seat_attach_session(Seat *s, Session *session) {
return 0;
}
-bool seat_is_vtconsole(Seat *s) {
+bool seat_is_seat0(Seat *s) {
assert(s);
-return s->manager->vtconsole == s;
+return s->manager->seat0 == s;
}
bool seat_can_multi_session(Seat *s) {
assert(s);
-if (!seat_is_vtconsole(s))
+if (!seat_is_seat0(s))
return false;
/* If we can't watch which VT is in the foreground, we don't
@@ -450,7 +450,7 @@ bool seat_can_multi_session(Seat *s) {
bool seat_can_tty(Seat *s) {
assert(s);
-return seat_is_vtconsole(s);
+return seat_is_seat0(s);
}
bool seat_has_master_device(Seat *s) {
@@ -508,7 +508,7 @@ int seat_check_gc(Seat *s, bool drop_not_started) {
if (drop_not_started && !s->started)
return 0;
-if (seat_is_vtconsole(s))
+if (seat_is_seat0(s))
return 1;
return seat_has_master_device(s);
diff --git a/src/login/logind-seat.h b/src/login/logind-seat.h
index bd5390f..47fe89a 100644
--- a/src/login/logind-seat.h
+++ b/src/login/logind-seat.h
@@ -60,7 +60,7 @@ int seat_preallocate_vts(Seat *s);
int seat_attach_session(Seat *s, Session *session);
-bool seat_is_vtconsole(Seat *s);
+bool seat_is_seat0(Seat *s);
bool seat_can_multi_session(Seat *s);
bool seat_can_tty(Seat *s);
bool seat_has_master_device(Seat *s);
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index 69a8ad7..ae91650 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -386,7 +386,7 @@ int session_activate(Session *s) {
if (s->seat->active == s)
return 0;
-assert(seat_is_vtconsole(s->seat));
+assert(seat_is_seat0(s->seat));
return chvt(s->vtnr);
}
diff --git a/src/login/logind.c b/src/login/logind.c
index ad3ab81..d18bb08 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -852,7 +852,7 @@ int manager_dispatch_vcsa_udev(Manager *m) {
* VTs, to make sure our auto VTs never go away. */
if (name && startswith(name, "vcsa") &&
streq_ptr(udev_device_get_action(d), "remove"))
-r = seat_preallocate_vts(m->vtconsole);
+r = seat_preallocate_vts(m->seat0);
udev_device_unref(d);
@@ -877,9 +877,9 @@ int manager_dispatch_button_udev(Manager *m) {
int manager_dispatch_console(Manager *m) {
assert(m);
+assert(m->seat0);
-if (m->vtconsole)
-seat_read_active_vt(m->vtconsole);
+seat_read_active_vt(m->seat0);
[PATCH 05/10] logind: introduce session-devices
uot; \
" \n"\
@@ -408,6 +428,100 @@ static DBusHandlerResult session_message_dispatch(
if (!reply)
goto oom;
+} else if (dbus_message_is_method_call(message,
"org.freedesktop.login1.Session", "RequestDevice")) {
+const char *node;
+SessionDevice *sd;
+bool b;
+dbus_bool_t paused;
+
+if (!session_is_controller(s,
bus_message_get_sender_with_fallback(message)))
+return bus_send_error_reply(connection, message, NULL,
-EPERM);
+
+if (!dbus_message_get_args(
+message,
+&error,
+DBUS_TYPE_STRING, &node,
+DBUS_TYPE_INVALID))
+return bus_send_error_reply(connection, message,
&error, -EINVAL);
+
+sd = hashmap_get(s->devices, node);
+if (sd) {
+/* We don't allow retrieving a device multiple times.
+ * The related ReleaseDevice call is not ref-counted.
+ * The caller should use dup() if it requires more than
+ * one fd (it would be functionally equivalent). */
+return bus_send_error_reply(connection, message,
&error, -EBUSY);
+}
+
+r = session_device_new(s, node, &sd);
+if (r < 0)
+return bus_send_error_reply(connection, message, NULL,
r);
+
+reply = dbus_message_new_method_return(message);
+if (!reply) {
+session_device_free(sd);
+goto oom;
+}
+
+paused = !sd->active;
+b = dbus_message_append_args(
+reply,
+DBUS_TYPE_UNIX_FD, &sd->fd,
+DBUS_TYPE_BOOLEAN, &paused,
+DBUS_TYPE_INVALID);
+if (!b) {
+session_device_free(sd);
+return bus_send_error_reply(connection, message, NULL,
-ENOMEM);
+}
+
+} else if (dbus_message_is_method_call(message,
"org.freedesktop.login1.Session", "ReleaseDevice")) {
+const char *node;
+SessionDevice *sd;
+
+if (!session_is_controller(s,
bus_message_get_sender_with_fallback(message)))
+return bus_send_error_reply(connection, message, NULL,
-EPERM);
+
+if (!dbus_message_get_args(
+message,
+&error,
+DBUS_TYPE_STRING, &node,
+DBUS_TYPE_INVALID))
+return bus_send_error_reply(connection, message,
&error, -EINVAL);
+
+sd = hashmap_get(s->devices, node);
+if (!sd)
+return bus_send_error_reply(connection, message, NULL,
-ENODEV);
+
+session_device_free(sd);
+
+reply = dbus_message_new_method_return(message);
+if (!reply)
+goto oom;
+
+} else if (dbus_message_is_method_call(message,
"org.freedesktop.login1.Session", "PauseDeviceComplete")) {
+const char *node;
+SessionDevice *sd;
+
+if (!session_is_controller(s,
bus_message_get_sender_with_fallback(message)))
+return bus_send_error_reply(connection, message, NULL,
-EPERM);
+
+if (!dbus_message_get_args(
+message,
+&error,
+DBUS_TYPE_STRING, &node,
+DBUS_TYPE_INVALID))
+return bus_send_error_reply(connection, message,
&error, -EINVAL);
+
+sd = hashmap_get(s->devices, node);
+if (!sd)
+return bus_send_error_reply(connection, message, NULL,
-ENODEV);
+
+session_device_complete_pause(sd);
+
+ reply = dbus_message_new_method_return(message);
+if (!reply)
+goto oom;
+
} else {
const BusBoundProperties bps[] = {
{ "org.freedesktop.login1.Session",
bus_login_session_properties, s },
diff --git a/src/login/logind-session-device.c
b/src/login/logind-session-device.c
new file mode 100644
index 000..7c6b07f
--- /dev/null
+++ b/src/login/logi
[PATCH 04/10] logind: make Session.Activate() lazy
Currently, Activate() calls chvt(), which does an ioctl(VT_ACTIVATE) and
immediately calls seat_set_active(). However, VTs are allowed to prevent
being deactivated. Therefore, logind cannot be sure the VT_ACTIVATE call
was actually successful.
Furthermore, compositors often need to clean up their devices before they
acknowledge the VT switch. The immediate call to seat_set_active() may
modify underlying ACLs, though. Thus, some compositors may fail cleaning
up their stuff. Moreover, the compositor being switched to (if listening
to logind instead of VTs) will not be able to activate its devices if the
old VT still has them active.
We could simply add an VT_WAITACTIVE call, which blocks until the given VT
is active. However, this can block forever if the compositor hangs.
So to fix this, we make Activate() lazy. That is, it only schedules a
session-switch but does not wait for it to complete. The caller can no
longer rely on it being immediate. Instead, a caller is required to wait
for the PropertiesChanged signal and read the "Active" field.
We could make Activate() wait asynchronously for the session-switch to
complete and then send the return-message afterwards. However, this would
add a lot of state-tracking with no real gain:
1) Sessions normally don't care whether Activate() was actually
successful as they currently _must_ wait for the VT activation to do
anything for real.
2) Error messages for failed session switches can be printed by logind
instead of the session issuing Activate().
3) Sessions that require synchronous Activate() calls can simply issue
the call and then wait for "Active" properties to change. This also
allows them to implement their own timeout.
This change prepares for multi-session on seats without VTs. Forced VT
switches are always bad as compositors cannot perform any cleanup. This
isn't strictly required, but may lead to loss of information and ambiguous
error messages.
So for multi-session on seats without VTs, we must wait for the current
session to clean-up before finalizing the session-switch. This requires
Activate() to be lazy as we cannot block here.
Note that we can always implement a timeout which allows us to guarantee
the session switch to happen. Nevertheless, this calls for a lazy
Activate().
---
src/login/logind-session.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index 6c6a2c8..a11804a 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -359,8 +359,6 @@ int session_load(Session *s) {
}
int session_activate(Session *s) {
-int r;
-
assert(s);
assert(s->user);
@@ -375,11 +373,7 @@ int session_activate(Session *s) {
assert(seat_is_vtconsole(s->seat));
-r = chvt(s->vtnr);
-if (r < 0)
-return r;
-
-return seat_set_active(s->seat, s);
+return chvt(s->vtnr);
}
static int session_link_x11_socket(Session *s) {
--
1.8.3.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 03/10] logind: add session controllers
A session usually has only a single compositor or other application that
controls graphics and input devices on it. To avoid multiple applications
from hijacking each other's devices or even using the devices in parallel,
we add session controllers.
A session controller is an application that manages a session. Specific
API calls may be limited to controllers to avoid others from getting
unprivileged access to restricted resources. A session becomes a
controller by calling the RequestControl() dbus API call. It can drop it
via ReleaseControl().
logind tracks bus-names to release the controller once an application
closes the bus. We use the new bus-name tracking to do that. Note that
during ReleaseControl() we need to check whether some other session also
tracks the name before we remove it from the bus-name tracking list.
Currently, we only allow one controller at a time. However, the public API
does not enforce this restriction. So if it makes sense, we can allow
multiple controllers in parallel later. Or we can add a "scope" parameter,
which allows a different controller for graphics-devices, sound-devices
and whatever you want.
Note that currently you get -EBUSY if there is already a controller. You
can force the RequestControl() call (root-only) to drop the current
controller and recover the session during an emergency. To recover a seat,
this is not needed, though. You can simply create a new session or
force-activate it.
To become a session controller, a dbus caller must either be root or the
same user as the user of the session. This allows us to run a session
compositor as user and we no longer need any CAP_SYS_ADMIN.
---
src/login/logind-dbus.c | 8 +++
src/login/logind-session-dbus.c | 42
src/login/logind-session.c | 48 +
src/login/logind-session.h | 6 ++
src/login/logind.c | 10 +
5 files changed, 114 insertions(+)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index eb62d28..a703e59 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -2472,8 +2472,16 @@ DBusHandlerResult bus_message_filter(
goto finish;
}
+/* drop all controllers owned by this name */
if (*old && !*new && (key = hashmap_remove(m->busnames, old)))
{
+Session *session;
+Iterator i;
+
free(key);
+
+HASHMAP_FOREACH(session, m->sessions, i)
+if (session_is_controller(session, old))
+session_drop_controller(session);
}
}
diff --git a/src/login/logind-session-dbus.c b/src/login/logind-session-dbus.c
index 2cc4d85..b8b32cd 100644
--- a/src/login/logind-session-dbus.c
+++ b/src/login/logind-session-dbus.c
@@ -40,6 +40,10 @@
" \n" \
" \n"\
" \n" \
+" \n" \
+" \n" \
+" \n" \
+" \n"\
" \n" \
" \n" \
" \n"\
@@ -366,6 +370,44 @@ static DBusHandlerResult session_message_dispatch(
if (!reply)
goto oom;
+} else if (dbus_message_is_method_call(message,
"org.freedesktop.login1.Session", "RequestControl")) {
+dbus_bool_t force;
+unsigned long ul;
+
+if (!dbus_message_get_args(
+message,
+&error,
+DBUS_TYPE_BOOLEAN, &force,
+DBUS_TYPE_INVALID))
+return bus_send_error_reply(connection, message,
&error, -EINVAL);
+
+ul = dbus_bus_get_unix_user(connection,
dbus_message_get_sender(message), &error);
+if (ul == (unsigned long) -1)
+return bus_send_error_reply(connection, message,
&error, -EIO);
+
+if (ul != 0 && (force || ul != s->user->uid))
+return bus_send_error_reply(connection, message, NULL,
-EPERM);
+
+r = session_set_controller(s,
bus_message_get_sender_with_fallback(message), force);
+if (r < 0)
+return bus_send_error_reply(connection, message, NULL,
r);
+
+reply = dbus_message_new_method_return(message);
+if (!reply)
+goto oom;
+
+} else if (dbus_message_is_method_call(message,
"org.freedesktop.login1.Session", "DropControl")) {
+
[PATCH 02/10] logind: add infrastructure to watch busnames
If we want to track bus-names to allow exclusive resource-access, we need
a way to get notified when a bus-name is gone. We make logind watch for
NameOwnerChanged dbus events and check whether the name is currently
watched. If it is, we remove it from the watch-list (notification for
other objects can be added in follow-up patches).
---
src/login/logind-dbus.c | 17
src/login/logind.c | 54 -
src/login/logind.h | 4
3 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 345df9f..eb62d28 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -2458,6 +2458,23 @@ DBusHandlerResult bus_message_filter(
HASHMAP_FOREACH(session, m->sessions, i)
session_add_to_gc_queue(session);
}
+
+} else if (dbus_message_is_signal(message, DBUS_INTERFACE_DBUS,
"NameOwnerChanged")) {
+const char *name, *old, *new;
+char *key;
+
+if (!dbus_message_get_args(message, &error,
+ DBUS_TYPE_STRING, &name,
+ DBUS_TYPE_STRING, &old,
+ DBUS_TYPE_STRING, &new,
+ DBUS_TYPE_INVALID)) {
+log_error("Failed to parse NameOwnerChanged message:
%s", bus_error_message(&error));
+goto finish;
+}
+
+if (*old && !*new && (key = hashmap_remove(m->busnames, old)))
{
+free(key);
+}
}
finish:
diff --git a/src/login/logind.c b/src/login/logind.c
index 54fb391..f4cef54 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -74,6 +74,7 @@ Manager *manager_new(void) {
m->users = hashmap_new(trivial_hash_func, trivial_compare_func);
m->inhibitors = hashmap_new(string_hash_func, string_compare_func);
m->buttons = hashmap_new(string_hash_func, string_compare_func);
+m->busnames = hashmap_new(string_hash_func, string_compare_func);
m->user_units = hashmap_new(string_hash_func, string_compare_func);
m->session_units = hashmap_new(string_hash_func, string_compare_func);
@@ -82,7 +83,7 @@ Manager *manager_new(void) {
m->inhibitor_fds = hashmap_new(trivial_hash_func,
trivial_compare_func);
m->button_fds = hashmap_new(trivial_hash_func, trivial_compare_func);
-if (!m->devices || !m->seats || !m->sessions || !m->users ||
!m->inhibitors || !m->buttons ||
+if (!m->devices || !m->seats || !m->sessions || !m->users ||
!m->inhibitors || !m->buttons || !m->busnames ||
!m->user_units || !m->session_units ||
!m->session_fds || !m->inhibitor_fds || !m->button_fds) {
manager_free(m);
@@ -111,6 +112,7 @@ void manager_free(Manager *m) {
Seat *s;
Inhibitor *i;
Button *b;
+char *n;
assert(m);
@@ -132,12 +134,16 @@ void manager_free(Manager *m) {
while ((b = hashmap_first(m->buttons)))
button_free(b);
+while ((n = hashmap_first(m->busnames)))
+free(hashmap_remove(m->busnames, n));
+
hashmap_free(m->devices);
hashmap_free(m->seats);
hashmap_free(m->sessions);
hashmap_free(m->users);
hashmap_free(m->inhibitors);
hashmap_free(m->buttons);
+hashmap_free(m->busnames);
hashmap_free(m->user_units);
hashmap_free(m->session_units);
@@ -361,6 +367,40 @@ int manager_add_button(Manager *m, const char *name,
Button **_button) {
return 0;
}
+int manager_watch_busname(Manager *m, const char *name) {
+char *n;
+int r;
+
+assert(m);
+assert(name);
+
+if (hashmap_get(m->busnames, name))
+return 0;
+
+n = strdup(name);
+if (!n)
+return -ENOMEM;
+
+r = hashmap_put(m->busnames, n, n);
+if (r < 0) {
+free(n);
+return r;
+}
+
+return 0;
+}
+
+void manager_drop_busname(Manager *m, const char *name) {
+char *key;
+
+assert(m);
+assert(name);
+
+key = hashmap_remove(m->busnames, name);
+if (key)
+free(key);
+}
+
int manager_process_seat_device(Manager *m, struct udev_device *d) {
Device *device;
int r;
@@ -1039,6 +1079,18 @@ static int manager_connect_bus(Manager *m) {
dbus_bus_add_match(m->bus,
"type='signal',"
+ "sender='"DBUS_SERVICE_DBUS"',"
+ "interface='"DBUS_INTERFACE_DBUS"',"
+ "member='NameOwnerChanged',"
+ "path='"DBUS_PAT
[PATCH 01/10] logind: listen actively for session devices
Session compositors need access to fbdev, DRM and evdev devices if they
control a session. To make logind pass them to sessions, we need to
listen for them actively.
However, we avoid creating new seats for non master-of-seat devices. Only
once a seat is created, we start remembering all other session devices. If
the last master-device is removed (even if there are other non-master
devices still available), we destroy the seat. This is the current
behavior, but we need to explicitly implement it now as there may be
non-master devices in the seat->devices list.
Unlike master devices, we don't care whether our list of non-master
devices is complete. We don't export this list but use it only as cache if
sessions request these devices. Hence, if a session requests a device that
is not in the list, we will simply look it up. However, once a session
requested a device, we must be notified of "remove" udev events. So we
must link the devices somehow into the device-list.
Regarding the implementation, we now sort the device list by the "master"
flag. This guarantees that master devices are at the front and non-master
devices at the tail of the list. Thus, we can easily test whether a seat
has a master device attached.
---
src/login/logind-device.c | 35 ++---
src/login/logind-device.h | 3 +-
src/login/logind-seat.c | 11 +--
src/login/logind-seat.h | 1 +
src/login/logind.c| 79 +--
src/login/logind.h| 6 ++--
6 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/src/login/logind-device.c b/src/login/logind-device.c
index 51b1535..a9a9633 100644
--- a/src/login/logind-device.c
+++ b/src/login/logind-device.c
@@ -25,7 +25,7 @@
#include "logind-device.h"
#include "util.h"
-Device* device_new(Manager *m, const char *sysfs) {
+Device* device_new(Manager *m, const char *sysfs, bool master) {
Device *d;
assert(m);
@@ -48,6 +48,7 @@ Device* device_new(Manager *m, const char *sysfs) {
}
d->manager = m;
+d->master = master;
dual_timestamp_get(&d->timestamp);
return d;
@@ -75,11 +76,16 @@ void device_detach(Device *d) {
LIST_REMOVE(Device, devices, d->seat->devices, d);
d->seat = NULL;
-seat_add_to_gc_queue(s);
-seat_send_changed(s, "CanGraphical\0");
+if (!seat_has_master_device(s)) {
+seat_add_to_gc_queue(s);
+seat_send_changed(s, "CanGraphical\0");
+}
}
void device_attach(Device *d, Seat *s) {
+Device *i;
+bool had_master;
+
assert(d);
assert(s);
@@ -90,7 +96,26 @@ void device_attach(Device *d, Seat *s) {
device_detach(d);
d->seat = s;
-LIST_PREPEND(Device, devices, s->devices, d);
+had_master = seat_has_master_device(s);
+
+/* We keep the device list sorted by the "master" flag. That is, master
+ * devices are at the front, other devices at the tail. As there is no
+ * way to easily add devices at the list-tail, we need to iterate the
+ * list to find the first non-master device when adding non-master
+ * devices. We assume there is only a few (normally 1) master devices
+ * per seat, so we iterate only a few times. */
+
+if (d->master || !s->devices) {
+LIST_PREPEND(Device, devices, s->devices, d);
+} else {
+LIST_FOREACH(devices, i, s->devices) {
+if (!i->devices_next || !i->master) {
+LIST_INSERT_AFTER(Device, devices, s->devices,
i, d);
+break;
+}
+}
+}
-seat_send_changed(s, "CanGraphical\0");
+if (!had_master && d->master)
+seat_send_changed(s, "CanGraphical\0");
}
diff --git a/src/login/logind-device.h b/src/login/logind-device.h
index 3b15356..315f0e6 100644
--- a/src/login/logind-device.h
+++ b/src/login/logind-device.h
@@ -33,13 +33,14 @@ struct Device {
char *sysfs;
Seat *seat;
+bool master;
dual_timestamp timestamp;
LIST_FIELDS(struct Device, devices);
};
-Device* device_new(Manager *m, const char *sysfs);
+Device* device_new(Manager *m, const char *sysfs, bool master);
void device_free(Device *d);
void device_attach(Device *d, Seat *s);
void device_detach(Device *d);
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index 470d08b..2c60b8a 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -448,10 +448,17 @@ bool seat_can_tty(Seat *s) {
return seat_is_vtconsole(s);
}
+bool seat_has_master_device(Seat *s) {
+assert(s);
+
+/* device list is ordered by "master" flag */
+return !!s->devices && s->devices->master;
+}
+
bool seat_can_graphical(Seat *s) {
assert(s);
-return
[PATCH 00/10] Device Management for systemd-logind
ht also be paused for other reasons that are currently not defined. This means, whenever a session is inactive, all devices on this session are inactive, too. However, when a session is active, a device might stay inactive (for instance if reactivation failed). But logind guarantees that a device can never be used by anyone else than the foreground session. Compositors can rely on that for security reasons. logind itselfs takes care of revoking device access for inactive sessions (synchronized with session-switches!). It also tries to resume every device when a session is activated. But session-devices must not be used to watch session state! A compositor has to use the PropertiesChanged() signal plus the "Active" property of sessions for that! Session-devices do not replace this! On sessions with VTs, this is obviously replaced by the VT_SETMODE interface as usual. Now additionally to the interface mentioned above, this series introduces session-controllers. These try to prevent multiple compositors from running in parallel. That is, when a compositor starts up, it calls RequestControl() on the session in question. If there is already another compositor running, this will fail. The new device-management functions are limited to the active controller. No other functions make use of controllers. Note that the RequestControl() call might get a "scope" argument. So you can have a controller with scope "graphics" and one for scope "sound", for example. On each scope only a single controller is allowed, but the scopes don't interfere. So logind makes sure that RequestDevice() on a graphics or input device requires the "graphics" scope. But now the API: RequestControl(bool force): For now this misses a "scope" argument, so it currently implies "graphics" scope. This function will make the caller the new controller of the given session. logind watches the system bus and automatically drops the controller once it disconnects. If there is already a controller for the given scope, this returns EBUSY. If @force is true, the active controller will be dropped and the caller will get the new controller. This function is restricted to callers with the same UID as the "User" of the given session. If @force is true, the caller must be root. So this call in combination with RequestDevice() allows us to run a compositor in a session as normal user. Yay! DropControl(): Drop control again. If the caller is not the current controller, this does nothing. Note that this call is optional. logind watches the bus for disconnect events and invokes this implicitly if a controller exits. David Herrmann (10): logind: listen actively for session devices logind: add infrastructure to watch busnames logind: add session controllers logind: make Session.Activate() lazy logind: introduce session-devices logind: rename vtconsole to seat0 logind: fix seat_can_tty() to check for VTs logind: fix session_activate(vtnr = 0) logind: extract has_vts() from can_multi_session() logind: implement generic multi-session Makefile.am | 2 + src/login/logind-dbus.c | 35 ++- src/login/logind-device.c | 39 ++- src/login/logind-device.h | 5 +- src/login/logind-seat.c | 73 -- src/login/logind-seat.h | 6 +- src/login/logind-session-dbus.c | 156 src/login/logind-session-device.c | 517 ++ src/login/logind-session-device.h | 58 + src/login/logind-session.c| 112 - src/login/logind-session.h| 8 + src/login/logind.c| 151 +-- src/login/logind.h| 12 +- 13 files changed, 1109 insertions(+), 65 deletions(-) create mode 100644 src/login/logind-session-device.c create mode 100644 src/login/logind-session-device.h -- 1.8.3.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: Sony clickpad support
Hi On Sat, Aug 17, 2013 at 9:49 AM, Peter Hutterer wrote: > On Thu, Aug 15, 2013 at 02:48:48PM -0700, Kristian Høgsberg wrote: >> On Thu, Aug 15, 2013 at 12:10:30PM +0100, Daniel Stone wrote: >> > Hi, >> > >> > On 15 August 2013 11:52, Peter Hutterer wrote: >> > > one of the things that should be done is to figure out _where_ features >> > > such >> > > as this are going to be handled. In the compositor, the compositor's >> > > input >> > > module, on the client side, ... ? I'm trying to figure out how to handle >> > > this correctly, but don't have much to show here just yet. >> > > >> > > For example, wl_pointer only has a button event, which means that a >> > > client >> > > cannot differ between a tap and a button click. no doubt this should be >> > > in a >> > > piece of shared code, but right now it's not quite sure what can be >> > > shared where yet. >> > >> > ... does it need to? >> >> I don't think we do... I think that from a client point of view, a >> touchpad/clickpad looks exactly like a wl_pointer. Gestures such as >> two-finger scrolling, double-tap-drag, two-finger clicks, interpreting >> clicking in different as different buttons etc can all be done in the >> compositor and sent as either wl_pointer button and move events or >> axis events (scroll, pinch, rotate). > > then you need gestures on the protocol. tapping is relatively uncomplicated, > scrolling somewhere along the same lines (until you consider that swipe and > two-finger scroll are overlapping and context-dependent). pinch and rotate > require either the raw touch point data for re-interpretation, or at least > the delta positions, possibly the pressure of the touchpoints, etc. then you > need the number of touchpoints, and to tell that the client beforehand so > they know whether they can expect a four-finger gesture or not. I think wl_pointer was intended as interfaces without gestures. All state-machines are inside the compositor. And honestly I think that's what most applications want. What you are suggesting is to allow applications to get raw touch data for touchpads/trackpads. As this data stream is quite heavy, I think we should avoid sending it to uninterested clients. So how about keeping wl_pointer as it is (and probably adding additional events similar to scrolling), but adding a get_touch() call to wl_pointer, which returns a wl_touch object for this exact pointer. It's the clients responsibility to notice that this is now used for relative, not absolute motion. Note that we have the "cancel" event on wl_touch which can cancel gestures if the parent wl_pointer already interpreted it. We can also add a bitmask to get_touch() which lets the client tell the compositor which gesture-detection to disable. So for instance a client could do 2-finger-scroll detection and convert it to whatever they want. They'd have to tell the compositor to disable it's own gesture detection, to avoid getting a "cancel" event and the axis-movement. Regards David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] Fixes CJK wide character display
Hi
On Wed, Aug 14, 2013 at 2:30 AM, Kristian Høgsberg wrote:
> On Thu, Aug 01, 2013 at 01:49:03PM +0800, Peng Wu wrote:
>> By jumping two columns when wide character prints,
>> and draw wide cursor under wide character.
>
> Hi Peng,
>
> I do want this feature in weston-terminal, but there's still a few
> issues to address - see below.
>
>> ---
>> clients/Makefile.am | 2 +-
>> clients/terminal.c | 26 --
>> 2 files changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/clients/Makefile.am b/clients/Makefile.am
>> index 09963cc..e7c0ece 100644
>> --- a/clients/Makefile.am
>> +++ b/clients/Makefile.am
>> @@ -113,7 +113,7 @@ weston_screenshooter_SOURCES =\
>> weston_screenshooter_LDADD = libtoytoolkit.la
>>
>> weston_terminal_SOURCES = terminal.c
>> -weston_terminal_LDADD = libtoytoolkit.la -lutil
>> +weston_terminal_LDADD = libtoytoolkit.la -lutil $(PANGO_LIBS)
>
> Again, I don't want to link to pango or glib... remember, the only
> reason for weston-terminal to exist is that it doesn't have any
> dependencies except cairo and the wayland libraries.
>
>> weston_image_SOURCES = image.c
>> weston_image_LDADD = libtoytoolkit.la
>> diff --git a/clients/terminal.c b/clients/terminal.c
>> index 0d4f726..dc56745 100644
>> --- a/clients/terminal.c
>> +++ b/clients/terminal.c
>> @@ -33,6 +33,10 @@
>> #include
>> #include
>> #include
>> +#include
>> +#define __USE_XOPEN
>> +#include
>> +#include
>>
>> #include
>>
>> @@ -93,6 +97,11 @@ union utf8_char {
>> uint32_t ch;
>> };
>>
>> +static bool is_wide(union utf8_char utf8){
>> + gunichar unichar = g_utf8_get_char((const char*) utf8.byte);
>> + return wcwidth(unichar) > 1;
>> +}
>
> ... but I just committed a patch to make the utf-8 state machine
> assemble the unicode value from the utf-8, so you can now use
> get_unicode() instead of g_utf8_get_char().
>
> Please follow the coding conventions and leave 'static int' on it's
> own line and put the opening '{' of the function on it's own line.
>
>> enum utf8_state {
>> utf8state_start,
>> utf8state_accept,
>> @@ -942,6 +951,7 @@ redraw_handler(struct widget *widget, void *data)
>> struct glyph_run run;
>> cairo_font_extents_t extents;
>> double average_width;
>> + double unichar_width;
>>
>> surface = window_get_surface(terminal->window);
>> widget_get_allocation(terminal->widget, &allocation);
>> @@ -967,6 +977,7 @@ redraw_handler(struct widget *widget, void *data)
>> allocation.y + top_margin);
>> /* paint the background */
>> for (row = 0; row < terminal->height; row++) {
>> + p_row = terminal_get_row(terminal, row);
>> for (col = 0; col < terminal->width; col++) {
>> /* get the attributes for this character cell */
>> terminal_decode_attr(terminal, row, col, &attr);
>> @@ -974,12 +985,17 @@ redraw_handler(struct widget *widget, void *data)
>> if (attr.attr.bg == terminal->color_scheme->border)
>> continue;
>>
>> + if(is_wide(p_row[col]))
>> + unichar_width = 2 * average_width;
>> + else
>> + unichar_width = average_width;
>> +
>> terminal_set_color(terminal, cr, attr.attr.bg);
>> cairo_move_to(cr, col * average_width,
>> row * extents.height);
>> - cairo_rel_line_to(cr, average_width, 0);
>> + cairo_rel_line_to(cr, unichar_width, 0);
>> cairo_rel_line_to(cr, 0, extents.height);
>> - cairo_rel_line_to(cr, -average_width, 0);
>> + cairo_rel_line_to(cr, -unichar_width, 0);
>> cairo_close_path(cr);
>> cairo_fill(cr);
>> }
>> @@ -1871,6 +1887,10 @@ handle_char(struct terminal *terminal, union
>> utf8_char utf8)
>> row[terminal->column] = utf8;
>> attr_row[terminal->column++] = terminal->curr_attr;
>>
>> + /* cursor jump for wide character. */
>> + if (is_wide(utf8))
>> + row[terminal->column++].ch = 0;
>
> Inserting this 0 here confuses the selection logic which thinks 0
> means "end of line". I think we can use an invalid utf-8 character
> instead to indicate that this cell is a wide-char filler. We then
> also need to handle that in terminal_send_selection(), where we must
> ignore those filler cells when writing the selection to the fd.
>
>
>> if (utf8.ch != terminal->last_char.ch)
>> terminal->last_char = utf8;
>> }
>> @@ -2711,6 +2731,8 @@ int main(int argc, char *argv[])
>> struct terminal *terminal;
>> int config_fd;
>>
>> + setlocale(LC_ALL, "");
>
> What is this for?
This is to work around the horrible glibc API. wcwidth() depend
Re: [PATCH v2 wayland] pkg-config: scanner isn't arch-independent
Hi On Fri, Aug 16, 2013 at 2:26 PM, Daniel Stone wrote: > $(datadir) rather than $(libdir), is for architecture-independent data. > pkg-config files should only be installed there if they're shareable > across architectures, e.g. headers/data only, which wayland-scanner is > not. Move it to $(libdir) with the other pkg-config files. > > Signed-off-by: Daniel Stone > --- > > v2: Oops, wasn't looking when I pulled this over from my other tree. > Fix = vs. +=. > > src/Makefile.am | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/src/Makefile.am b/src/Makefile.am > index 4226f63..efdfaf4 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -58,8 +58,7 @@ wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la > > $(BUILT_SOURCES) : wayland-scanner > > -scannerpkgconfigdir = $(datadir)/pkgconfig > -scannerpkgconfig_DATA = wayland-scanner.pc > +pkgconfig_DATA += wayland-scanner.pc Yepp, we should definitely use pkgconfig_DATA. Reviewed-by: David Herrmann Cheers David > endif > > BUILT_SOURCES =\ > -- > 1.8.3.1 > > ___ > 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: [RFC] weston: Sony clickpad support
Hi On Tue, Aug 13, 2013 at 6:50 AM, Alexander E. Patrakov wrote: > 2013/8/12 David Herrmann : > >> The implementation looks quite nice. I will not comment on the code >> individually, though. I'd really like to see a libtouchpad which >> implements all that logic. Once we start adding device drivers to >> weston, we will end up with a mess where we have to port it to each >> compositor we write. If gnome-shell becomes a compositor, it needs to >> implement this again. >> >> libxkbcommon already abstracted the keyboard handling. Why not do the >> same for touchpads? The "wl_touch" interface to weston is already >> standardized, so all this library needs to provide is a state-machine >> that converts evdev events into something similar to wl_touch. >> >> It's currently on my TODO list, so feel free to ignore it. But imho we >> should try to keep user-space input drivers separate to allow reuse >> and uniform configurations. > > If you set up a git repository for libtouchpad, I will help with the code > there. > > OTOH I don't yet agree with the use of wl_touch as the output of such > library. In the wl_touch documentation, touchscreens are mentioned, > not touchpads. With touchpads, people often talk about moving the > pointer, hovering, clicking and scrolling (even though scrolling is a > gesture), and that fits better under wl_pointer. Whoops, sure, wl_mouse it is. I just confused wl_touch with touchpads, sorry. I did think about it a bit more and I guess pushing into weston is fine so far. But once we start duplicating it for gnome-shell/etc. we should start thinking about a separate library. I will happily create a repository, but that will have to wait until late September as I am swamped with gsoc work until then. Cheers David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: Sony clickpad support
Hi On Mon, Aug 5, 2013 at 12:34 PM, Alexander E. Patrakov wrote: > This patch series adds support to weston for a special type of touchpads > found in some laptops. These touchpads contain one physical button that > covers the whole surface of the touchpad. Unlike the well-known Apple > touchpad, these touchpads have markings painted on them, that designate > virtual button areas. So the user interaction is quite different from one > gets from Apple touchpads. > > +---+ > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\/\/\/\/\/\/\/\/\/\/\/\/\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\ Cursor-moving area /\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\/\/\/\/\/\/\/\/\/\/\/\/\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > +---+ <-- painted line > | Left | Right | > | virtual| virtual| > | button | button | > +-+-+ > ^ > | > painted line > > E.g., currently, in order to get a right-click on such "clickpad", one has > to click anywhere with two fingers. This is, however, inappropriate for > touchpads I am talking about. See: one needs to drag something, he places a > finger on the upper part of the touchpad surface (on the part of surface > designated for moving the cursor), then places another finger into the > left half of the button area, clicks with the intention to move the first > finger. However, what he currently gets is a right-click. Also, if one > wants to make a right click, he places his finger into the right half of > the button area, clicks, but currently gets a left click. In other words, > the touchpad is unusable for users that are accustomed to the way the > interaction with the touchpad is done in Windows. > > I have implemented the interaction model that looks more like what one > gets in Windows. In order to do so, I had to refactor the existing code a > bit and add support for multitouch protocol to evdev-touchpad.c. > > Tested all of this on my Sony VAIO VPC-Z23A4R laptop. Here is what works: > > * Moving the cursor by moving the finger in the cursor-moving area of >the touchpad. > * Not moving the cursor if one moves the finger in the virtual button >area. > * Tap-to-click. > * Tap-and-drag gesture (unreliable). > * Left and right virtual buttons. > * Dragging, as explaining above. > * Insensitivity to bad clicks (those outside the designated button area). > * Two-finger scrolling. > > ...i.e. the touchpad is now quite usable. Zoom gestures are not implemented, > though. > > I have also added autodetection of the interaction model based on the > laptops with clickpads that GUADEC participants brought with themselves. > Result: the current interaction model is valid only for Apple and Chromebook > Pixel laptops, for everyone else the alternative model in this patch is > needed because there are buttons painted on the clickpad. The implementation looks quite nice. I will not comment on the code individually, though. I'd really like to see a libtouchpad which implements all that logic. Once we start adding device drivers to weston, we will end up with a mess where we have to port it to each compositor we write. If gnome-shell becomes a compositor, it needs to implement this again. libxkbcommon already abstracted the keyboard handling. Why not do the same for touchpads? The "wl_touch" interface to weston is already standardized, so all this library needs to provide is a state-machine that converts evdev events into something similar to wl_touch. It's currently on my TODO list, so feel free to ignore it. But imho we should try to keep user-space input drivers separate to allow reuse and uniform configurations. Cheers David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.
Hi On Thu, Aug 1, 2013 at 10:39 AM, Stefan Schmidt wrote: > Treating some specific sensors as input devices. In particular > adding support for wl_compass, wl_gyroscope and wl_accelerometer here. > > We have requests to start and stop sensor event receiving as well as > events to receive the different axis values for these sensors. > > Signed-off-by: Stefan Schmidt > --- > protocol/wayland.xml | 123 > ++ > 1 file changed, 123 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 3cfa953..066a718 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1251,6 +1251,9 @@ > > > > + > + > + If we add all kinds of devices here, we will very soon run out of space for 32bit bitfields (which I think wayland uses for "uint"). I don't have a solution, but we should keep this in mind. > > > > @@ -1297,6 +1300,39 @@ > > > > + > + > +The ID provided will be initialized to the wl_compass interface > + for this seat. > + > +This request only takes effect if the seat has the compass > +capability. > + > + > + > + > + > + > +The ID provided will be initialized to the wl_gyroscope interface > + for this seat. > + > +This request only takes effect if the seat has the gyroscope > +capability. > + > + > + > + > + > + > +The ID provided will be initialized to the wl_accelerometer interface > + for this seat. > + > +This request only takes effect if the seat has the accelerometer > +capability. > + > + > + > + This interface limits each seat to one device of each. For keyboards or mouse we internally merge these into a single virtual device, but we cannot do this for accelerometers or gyros. We had a discussion about that recently, I am not sure about the conclusion, though. If there was one, please include it in the commit message. Besides, why are these devices bound to seats? Where are these devices supposed to be? An accelerometer can be attached to an input device, an HDD, a laptop, a tablet, ... If you look at this from a smartphone/tablet view, it is obvious. But for desktops it really isn't clear whose data an accelerometer device reports. I guess these devices are meant to be attached to the input device that this seat/user uses. In this case it makes sense to allow only a single device and bind them to seats. But please clarify this in the description. No one cares if the description is 1000 words long, so feel free to be verbose. > > > In a multiseat configuration this can be used by the client to help > @@ -1605,6 +1641,93 @@ > > > > + > + > + The wl_compass interface represents a compass > + associated with a seat. > + > + > + > + > + Sent to enable event receiving for the compass sensor. > + > + > + > + > + > + Sent to disable event receiving for the compass sensor. > + > + So this is a shared device. Please note that down. A compositor has to broadcast events to all interested clients, otherwise this API doesn't work (or is inconsistent). Did you think of the implications of that? Might be fine, but I don't see any discussion, so please elaborate. What are the reasons to allow background applications to access compass/accelerometer/gyro? That is, why didn't you follow the enter/leave API? I don't want change your API, but the short descriptions give me the impression that you didn't think about these implications so I'd like to see some explanations. And the longer the descriptions, the less bikeshed you get.. as usual. This actually poses a security risk, please have a look at: http://arstechnica.com/apple/2011/10/researchers-can-keylog-your-pc-using-your-iphones-accelerometer/ > + > + > + > + Updated sensor data available from compass > + > + > + > + > + I never worked with compass devices on linux and it isn't obvious to me what these 3 axes represent? An explanation would really help here. But maybe I am just missing some context.. > + > + > + > + > + > + The wl_gyroscope interface represents a gyroscope > + associated with a seat. > + > + > + > + > + Sent to enable event receiving for the gyroscope sensor. > + > + > + > + > + > + Sent to disable event receiving for the gyroscope sensor. > + > + > + > + > + > + Updated sensor data available from gyroscope > + > + > + > + > + Here it is obvious what the 3 axes mean, but we should clarify that these are randomly chosen. At least I am not aware of any definitions which axes x, y and z are (for instance regarding the yaw/pitch/roll definitions). > + > + > + > + >
Re: [PATCH v2 1/3] Handle CJK wide glyph rendering
Hi On Tue, Jul 23, 2013 at 9:49 AM, Peng Wu wrote: > Hi, > > On Tue, 2013-07-23 at 09:22 +0200, David Herrmann wrote: >> Please first address the issues I mentioned in v1. You cannot just >> redraw characters and be fine. That's not how it works. You need to >> adjust handle_char() to move the cursor two columns for >> wide-characters. >> > Actually I also adjusted the cursor positioning and drawing in v2 patch > set. > > [PATCH v2 2/3] Fixes cursor rendering for wide glyphs > > Show the cursor at the right position, and use wide cursor under wide > glyph. That's not what I am talking about. This is about _drawing_ the cursor at the right position. I am talking about positioning the cursor _internally_. That is, the x/y cursor position. Your patch just moves the visual cursor according to your wide-characters. See the two examples below about internal cursor positions. >> Imagine MODE_AUTOWRAP is set and you draw 10 wide-characters on a 10 >> cell-line. We expect a vt320-compat terminal to draw 5 chars on the >> first line and the other 5 chars on the next line. >> >> Assume MODE_AUTOWRAP not set and you draw 10 wide-characters on a 10 >> cell-line. We expect the first 4 chars on the line and the last char >> to be the last character written. >> > I plan to skip to support MODE_AUTOWRAP feature. Ugh? I gave two examples, one with and one without MODE_AUTOWRAP. So it doesn't matter whether you support it or not, in both cases it will fail. If you don't implement it properly, you will soon notice that stuff like vim will fail. They rely on these features. >> Really, multi-width characters isn't about drawing. It's about >> correctly interpreting the incoming characters in your vt100-like >> state-machine. Why do you want to support that in terminal.c anyway? >> It's an example, it misses support for a lot of things and I recommend >> avoiding adding complex features. >> > Because we want weston terminal has i18n support, such as CJK glyph > display. I recommend keeping it simple. But it's not me to judge. If you refuse to implement it properly, I have no reason to review that. You need to convince krh to apply it. >> Anyhow, here is an example how to move the cursor for multi-width >> characters: >> https://github.com/dvdhrm/kmscon/blob/master/src/tsm_screen.c#L1000 Cheers David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 1/3] Handle CJK wide glyph rendering
Hi
On Tue, Jul 23, 2013 at 4:44 AM, Peng Wu wrote:
> Yes, I just followed the gnome vte terminal widget code.
> I will try to send v3 patch set to remove glib dependencies soon.
Please first address the issues I mentioned in v1. You cannot just
redraw characters and be fine. That's not how it works. You need to
adjust handle_char() to move the cursor two columns for
wide-characters.
Imagine MODE_AUTOWRAP is set and you draw 10 wide-characters on a 10
cell-line. We expect a vt320-compat terminal to draw 5 chars on the
first line and the other 5 chars on the next line.
Assume MODE_AUTOWRAP not set and you draw 10 wide-characters on a 10
cell-line. We expect the first 4 chars on the line and the last char
to be the last character written.
Really, multi-width characters isn't about drawing. It's about
correctly interpreting the incoming characters in your vt100-like
state-machine. Why do you want to support that in terminal.c anyway?
It's an example, it misses support for a lot of things and I recommend
avoiding adding complex features.
Anyhow, here is an example how to move the cursor for multi-width characters:
https://github.com/dvdhrm/kmscon/blob/master/src/tsm_screen.c#L1000
Regards
David
> On Sun, 2013-07-21 at 23:22 -0500, Thomas Daede wrote:
>> This is for a VT-100 style terminal emulator, right? It's designed to
>> implement a grid of characters. Therefore, drawing it like a grid
>> based on single or double character widths makes a lot more sense than
>> detecting the length of a string. On any other UI element, detecting
>> the string length would be more appropriate.
>>
>> Ideally I would imagine you would always pick a fixed width font (aka
>> only single or double widths) but the terminal should work "okay" with
>> a proportional font, forcing it into fixed positions.
>>
>> I think Peng's implementation is in line with other virtual terminals.
>>
>> On Sun, Jul 21, 2013 at 9:46 PM, Peng Wu wrote:
>> > Frankly speaking, I suspect that your new fix will break some program
>> > which uses newt with proportional font.
>> > PS: newt is a library for text mode user interfaces.
>> >
>> >
>> > On Thu, 2013-07-18 at 11:23 -0700, Bill Spitzak wrote:
>> >> I propose the drawing code be changed to something like this:
>> >>
>> >>char* string = the_line_to_draw;
>> >>cairo_draw_text_at(x, y, string);
>> >>
>> >> And this:
>> >>
>> >> int where_is_position_n(int n, char* string) {
>> >>return cairo_text_width(string, n);
>> >> }
>> >
>> >
>> > ___
>> > wayland-devel mailing list
>> > wayland-devel@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Some CJK glyphs are wide, which occupy two columns. If the glyph is wide, then use two columns instead of one.
Hi
On Thu, Jun 6, 2013 at 9:32 AM, Peng Wu wrote:
> ---
Please cut the headline and instead provide a proper commit message.
> clients/Makefile.am | 2 +-
> clients/terminal.c | 18 --
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/clients/Makefile.am b/clients/Makefile.am
> index cad0d40..d37d66a 100644
> --- a/clients/Makefile.am
> +++ b/clients/Makefile.am
> @@ -104,7 +104,7 @@ weston_screenshooter_SOURCES = \
> weston_screenshooter_LDADD = libtoytoolkit.la
>
> weston_terminal_SOURCES = terminal.c
> -weston_terminal_LDADD = libtoytoolkit.la -lutil
> +weston_terminal_LDADD = libtoytoolkit.la -lutil $(PANGO_LIBS)
>
> image_SOURCES = image.c
> image_LDADD = libtoytoolkit.la
> diff --git a/clients/terminal.c b/clients/terminal.c
> index 0d4f726..4495530 100644
> --- a/clients/terminal.c
> +++ b/clients/terminal.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -942,6 +943,9 @@ redraw_handler(struct widget *widget, void *data)
> struct glyph_run run;
> cairo_font_extents_t extents;
> double average_width;
> + gunichar unichar;
> + gboolean iswide;
> + int extracol;
>
> surface = window_get_surface(terminal->window);
> widget_get_allocation(terminal->widget, &allocation);
> @@ -991,22 +995,32 @@ redraw_handler(struct widget *widget, void *data)
> glyph_run_init(&run, terminal, cr);
> for (row = 0; row < terminal->height; row++) {
> p_row = terminal_get_row(terminal, row);
> + extracol = 0;
> for (col = 0; col < terminal->width; col++) {
> /* get the attributes for this character cell */
> terminal_decode_attr(terminal, row, col, &attr);
>
> glyph_run_flush(&run, attr);
>
> - text_x = col * average_width;
> + /* check dual width unicode character */
> + unichar = g_utf8_get_char((const char*)
> p_row[col].byte);
> + iswide = g_unichar_iswide(unichar);
> +
> + text_x = (col + extracol) * average_width;
> text_y = extents.ascent + row * extents.height;
> if (attr.attr.a & ATTRMASK_UNDERLINE) {
> terminal_set_color(terminal, cr,
> attr.attr.fg);
> cairo_move_to(cr, text_x, (double)text_y +
> 1.5);
> - cairo_line_to(cr, text_x + average_width,
> (double) text_y + 1.5);
> + if (iswide)
> + cairo_line_to(cr, text_x +
> average_width * 2, (double) text_y + 1.5);
> + else
> + cairo_line_to(cr, text_x +
> average_width, (double) text_y + 1.5);
> cairo_stroke(cr);
> }
>
> glyph_run_add(&run, text_x, text_y, &p_row[col]);
> + if (iswide)
> + extracol++;
This patch is actually wrong. multi-width character support requires
more than just drawing the glyphs with multiple columns. In fact, if a
client sends a multi-width character, the terminal emulation is
supposed to jump two columns so the next character will be inserted at
the correct position (this includes automatic newline, tabs, etc..).
What you currently do is just dropping the glyph which is inserted
after the double-col glyph. Are you sure this works as expected?
And for a wcwidth() implementation, see here:
https://github.com/dvdhrm/kmscon/blob/master/external/wcwidth.c
Just copy it verbatim and use wcwidth() instead of glib.
I recommend just leaving multi-width support out of terminal.c. It
adds complexity (including wcwidth()) and seems misplaced in a debug
helper like weston-terminal. But feel free to resend and I will try to
review it.
Cheers
David
> }
> }
>
> --
> 1.8.1.4
>
> ___
> 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 05/18] fbdev: initialize yoffset of varinfo
Hi Marc
On Fri, Jun 21, 2013 at 2:17 PM, Marc Chalain wrote:
>
>
> 2013/6/21 David Herrmann
>>
>> Hi
>>
>> On Fri, Jun 21, 2013 at 12:05 PM, Marc Chalain
>> wrote:
>> >
>> >
>> > 2013/6/21 David Herrmann
>> >>
>> >> Hi
>> >>
>> >> On Fri, Jun 21, 2013 at 11:43 AM, Marc Chalain
>> >> wrote:
>> >> >
>> >> > 2013/6/21 David Herrmann
>> >> >>
>> >> >> Hi
>> >> >>
>> >> >> On Fri, Jun 21, 2013 at 10:49 AM, mchalain [marc.chal...@gmail.com]
>> >> >> wrote:
>> >> >> > From: mchalain
>> >> >> >
>> >> >> > it initializes varinfo.yoffset. varinfo.yoffset has to
>> >> >> > point on the beginning of the video memory.
>> >> >> > The card uses this value to push on the screen a part of
>> >> >> > the video memory when this one is larger than the screen.
>> >> >> >
>> >> >> > ---
>> >> >> > weston/src/compositor-fbdev.c |6 ++
>> >> >> > 1 file changed, 6 insertions(+)
>> >> >> >
>> >> >> > diff --git a/weston/src/compositor-fbdev.c
>> >> >> > b/weston/src/compositor-fbdev.c
>> >> >> > index adfb67a..d2aee9b 100644
>> >> >> > --- a/weston/src/compositor-fbdev.c
>> >> >> > +++ b/weston/src/compositor-fbdev.c
>> >> >> > @@ -368,6 +368,11 @@ fbdev_query_screen_info(struct fbdev_output
>> >> >> > *output, int fd,
>> >> >> > return -1;
>> >> >> > }
>> >> >> >
>> >> >> > + if (varinfo.yoffset != 0) {
>> >> >> > + varinfo.yoffset = 0;
>> >> >> > + if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
>> >> >> > + return -1;
>> >> >> > + }
>> >> >>
>> >> >> Why do you need this? It's unnecessary. We call FBIOPUT_VSCREENINFO
>> >> >> after fbdev_query_screen_info(), anyway. Furthermore, not all
>> >> >> drivers
>> >> >> support panning even though the yoffset may be non-zero (you need
>> >> >> FBIOPUT_VSCREENINFO then).
>> >> >>
>> >> >> I think you can just drop this here but keep the yoffset=0 below.
>> >> >>
>> >> >
>> >> > where do you use FBIOPUT_VSCREENINFO ? I only find inside
>> >> > fbdev_set_screen_info but this function is called only when the
>> >> > output
>> >> > is
>> >> > reenable not at the startup.
>> >>
>> >> My bad!
>> >> But still, you now call FBIOPAN_DISPLAY on _every_
>> >> fbdev_query_screen_info() while it is only needed during initial setup
>> >> as VT_ENTER calls fbdev_set_screen_info(), anyway. So instead, I'd
>> >> recommend to just call fbdev_set_screen_info() during initial setup as
>> >> well.
>> >>
>> >
>> > No I call FBIOPAN_DISPLAY only at startup after yoffset is set to 0
>>
>> You call it everytime yoffset isn't 0. So if you VT_LEAVE, another
>> application changes the yoffset for whatever reason and we VT_ENTER,
>> you will end up calling FBIOPAN_DISPLAY again followed by
>> fbdev_set_screen_info() if the screen-info changed.
>>
>> Don't expect applications on other VTs to behave as expected. They may
>> do anything! They may even use some acceleration which we in weston
>> aren't aware of.
>>
> If another application set yoffset, with VT_ENTER we pass inside
> fbdev_set_screen_info
> and yoffset is set to 0.
> After fbdev_set_screen_info is buggy and this patch is not a bugfix...
> the bug is you set varinfo.bits_per_pixel with a value that could be
> different of 32 and
> after you set the colors as A8R8G8B8 ...
> I don't want to use it, because I can't check all cases of this function, my
> card is too simple...
Sorry, I cannot follow. It's the following scenario that I think can
be handled better:
WESTON-START
=> fbdev initialization
=> FBIOPAN_DISPLAY
VT_LEAVE
(some other app changes the fbdev state and offsets)
VT_ENTER
=> fbdev_output_reenable()
=> fbdev_frame_buffer_open()
=> fbdev_query_screen
Re: [PATCH 05/18] fbdev: initialize yoffset of varinfo
Hi
On Fri, Jun 21, 2013 at 12:05 PM, Marc Chalain wrote:
>
>
> 2013/6/21 David Herrmann
>>
>> Hi
>>
>> On Fri, Jun 21, 2013 at 11:43 AM, Marc Chalain
>> wrote:
>> >
>> > 2013/6/21 David Herrmann
>> >>
>> >> Hi
>> >>
>> >> On Fri, Jun 21, 2013 at 10:49 AM, mchalain [marc.chal...@gmail.com]
>> >> wrote:
>> >> > From: mchalain
>> >> >
>> >> > it initializes varinfo.yoffset. varinfo.yoffset has to
>> >> > point on the beginning of the video memory.
>> >> > The card uses this value to push on the screen a part of
>> >> > the video memory when this one is larger than the screen.
>> >> >
>> >> > ---
>> >> > weston/src/compositor-fbdev.c |6 ++
>> >> > 1 file changed, 6 insertions(+)
>> >> >
>> >> > diff --git a/weston/src/compositor-fbdev.c
>> >> > b/weston/src/compositor-fbdev.c
>> >> > index adfb67a..d2aee9b 100644
>> >> > --- a/weston/src/compositor-fbdev.c
>> >> > +++ b/weston/src/compositor-fbdev.c
>> >> > @@ -368,6 +368,11 @@ fbdev_query_screen_info(struct fbdev_output
>> >> > *output, int fd,
>> >> > return -1;
>> >> > }
>> >> >
>> >> > + if (varinfo.yoffset != 0) {
>> >> > + varinfo.yoffset = 0;
>> >> > + if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
>> >> > + return -1;
>> >> > + }
>> >>
>> >> Why do you need this? It's unnecessary. We call FBIOPUT_VSCREENINFO
>> >> after fbdev_query_screen_info(), anyway. Furthermore, not all drivers
>> >> support panning even though the yoffset may be non-zero (you need
>> >> FBIOPUT_VSCREENINFO then).
>> >>
>> >> I think you can just drop this here but keep the yoffset=0 below.
>> >>
>> >
>> > where do you use FBIOPUT_VSCREENINFO ? I only find inside
>> > fbdev_set_screen_info but this function is called only when the output
>> > is
>> > reenable not at the startup.
>>
>> My bad!
>> But still, you now call FBIOPAN_DISPLAY on _every_
>> fbdev_query_screen_info() while it is only needed during initial setup
>> as VT_ENTER calls fbdev_set_screen_info(), anyway. So instead, I'd
>> recommend to just call fbdev_set_screen_info() during initial setup as
>> well.
>>
>
> No I call FBIOPAN_DISPLAY only at startup after yoffset is set to 0
You call it everytime yoffset isn't 0. So if you VT_LEAVE, another
application changes the yoffset for whatever reason and we VT_ENTER,
you will end up calling FBIOPAN_DISPLAY again followed by
fbdev_set_screen_info() if the screen-info changed.
Don't expect applications on other VTs to behave as expected. They may
do anything! They may even use some acceleration which we in weston
aren't aware of.
>> > It seems strange that FBIOPAN_DISPLAY is not supported by some devices.
>> > I
>> > used this one to not set all the varinfo on the device and to be faster.
>>
>> See ./drivers/video/fbmem.c fb_pan_display(). Trivial fbdev drivers
>> might not support it, but user-space can still set the offset via
>> FBIOPUT_VSCREENINFO. If you want, you can call FBIOPAN_DISPLAY and if
>> it fails, you use FBIOPUT_VSCREENINFO.
>>
> I read the yoffset hasn't to be null in FB_VMODE_YWRAP . But yoffset is
> only used for panning.
> It's useless to set it if it doesn't use (fbmem.c uses yoffset only for
> panning in your example too)
A driver may not support FBIOPAN_DISPLAY but still support panning via
FBIOPUT_VSCREENINFO. If any framebuffer parameter change requires a
full modeset, there is no reason to support FBIOPAN_DISPLAY. But
panning may still be supported via yoffset and FBIOPUT_VSCREENINFO.
Cheers
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 05/18] fbdev: initialize yoffset of varinfo
Hi
On Fri, Jun 21, 2013 at 11:43 AM, Marc Chalain wrote:
>
> 2013/6/21 David Herrmann
>>
>> Hi
>>
>> On Fri, Jun 21, 2013 at 10:49 AM, mchalain [marc.chal...@gmail.com]
>> wrote:
>> > From: mchalain
>> >
>> > it initializes varinfo.yoffset. varinfo.yoffset has to
>> > point on the beginning of the video memory.
>> > The card uses this value to push on the screen a part of
>> > the video memory when this one is larger than the screen.
>> >
>> > ---
>> > weston/src/compositor-fbdev.c |6 ++
>> > 1 file changed, 6 insertions(+)
>> >
>> > diff --git a/weston/src/compositor-fbdev.c
>> > b/weston/src/compositor-fbdev.c
>> > index adfb67a..d2aee9b 100644
>> > --- a/weston/src/compositor-fbdev.c
>> > +++ b/weston/src/compositor-fbdev.c
>> > @@ -368,6 +368,11 @@ fbdev_query_screen_info(struct fbdev_output
>> > *output, int fd,
>> > return -1;
>> > }
>> >
>> > + if (varinfo.yoffset != 0) {
>> > + varinfo.yoffset = 0;
>> > + if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
>> > + return -1;
>> > + }
>>
>> Why do you need this? It's unnecessary. We call FBIOPUT_VSCREENINFO
>> after fbdev_query_screen_info(), anyway. Furthermore, not all drivers
>> support panning even though the yoffset may be non-zero (you need
>> FBIOPUT_VSCREENINFO then).
>>
>> I think you can just drop this here but keep the yoffset=0 below.
>>
>
> where do you use FBIOPUT_VSCREENINFO ? I only find inside
> fbdev_set_screen_info but this function is called only when the output is
> reenable not at the startup.
My bad!
But still, you now call FBIOPAN_DISPLAY on _every_
fbdev_query_screen_info() while it is only needed during initial setup
as VT_ENTER calls fbdev_set_screen_info(), anyway. So instead, I'd
recommend to just call fbdev_set_screen_info() during initial setup as
well.
> It seems strange that FBIOPAN_DISPLAY is not supported by some devices. I
> used this one to not set all the varinfo on the device and to be faster.
See ./drivers/video/fbmem.c fb_pan_display(). Trivial fbdev drivers
might not support it, but user-space can still set the offset via
FBIOPUT_VSCREENINFO. If you want, you can call FBIOPAN_DISPLAY and if
it fails, you use FBIOPUT_VSCREENINFO.
> If yoffset may be non-zero this backend shouldn't work this kind of devices
> and we have to change the painting functions.
yoffset=0; is the correct thing to do.
Cheers
David
>> > return 1;
>> > }
>> >
>> > @@ -404,6 +409,7 @@ fbdev_set_screen_info(struct fbdev_output *output,
>> > int fd,
>> > varinfo.blue.length = 8;
>> > varinfo.blue.msb_right = 0;
>> >
>> > + varinfo.yoffset = 0;
>>
>> Yep, this is definitely needed.
>>
>> Regards
>> David
>>
>> > /* Set the device's screen information. */
>> > if (ioctl(fd, FBIOPUT_VSCREENINFO, &varinfo) < 0) {
>> > return -1;
>> > --
>> > 1.7.9.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 1/2] Handle SYN_DROPPED, filter keys with a bitmap
Hi
On Tue, Jun 4, 2013 at 8:47 PM, Martin Minarik
wrote:
> Since evdev keys are unreliable, they might randomly get dropped, such
> as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered.
Ugh, if events are dropped but SYN_DROPPED is missing, it's a kernel
bug. Please report it to linux-in...@vger.kernel.org if you see it. We
shouldn't assume this broken behavior in user-space!
There is also a fix pending on linux-input@vger which fixes duplicate
press/release events on EVIOCGKEY. So lets fix such bugs upstream
instead of introducing hacks.
Nevertheless, SYN_DROPPED handling is needed, indeed.
> Clients, compositor are not able to recover from duplicate press/release.
> This fixes this bug, thereby making the compositor and clients useable
> even under critical system conditions such as, but not limited to, high
> system load, device malfunction. This improves reliability.
>
> Every device contains a key bitmap. Each passing key press/release
> is checked and recorded. Duplicated presses, releases are handled by
> emitting the opposite type event in between (the time is faked -1 time unit).
> This is a last resort solution and happens only very rarely.
>
> When a SYN_DROPPED is detected:
> 1 wait until after the next SYN_REPORT.
Why wait for SYN_REPORT? Re-reading system state should be a "silent"
operation. But see below
> 2 Ask the kernel for the actual state of buttons
> 3 Compare the buttons with the internal key bitmap, to see what changed.
> 4 Send each different key via notify to the compositor, with timestamp.
> 5 Update the internal key bitmap to match the kernel's
>
> Disadvantages of this approach
> Each evdev device consumes 96 bytes more memory.
> Table lookup+bit toggle for almost key.
> Don't know the timestamp of missing keys.
> The key_notify from kernel bitmap compare occurs later the real missing event.
> That's a timestamp issue.
>
> ---
> src/evdev-touchpad.c | 51 ++-
> src/evdev.c | 176
> ++
> src/evdev.h | 35 +++---
> 3 files changed, 208 insertions(+), 54 deletions(-)
>
> diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
> index a21ae0b..890ddad 100644
> --- a/src/evdev-touchpad.c
> +++ b/src/evdev-touchpad.c
> @@ -533,6 +533,26 @@ on_release(struct touchpad_dispatch *touchpad)
> push_fsm_event(touchpad, FSM_EVENT_RELEASE);
> }
>
> +struct evdev_dispatch_interface touchpad_interface;
> +struct evdev_dispatch_interface touchpad_syn_drop_interface;
> +
> +static inline void
> +process_syn(struct touchpad_dispatch *touchpad,
> +struct evdev_device *device,
> +struct input_event *e, uint32_t time)
> +{
> + switch (e->code) {
> + case SYN_DROPPED:
> + if (device->dispatch->interface == &touchpad_interface)
> + device->dispatch->interface =
> &touchpad_syn_drop_interface;
> + break;
> + case SYN_REPORT:
> + default:
> + touchpad->event_mask |= TOUCHPAD_EVENT_REPORT;
> + break;
> + }
> +}
> +
> static inline void
> process_absolute(struct touchpad_dispatch *touchpad,
> struct evdev_device *device,
> @@ -588,7 +608,7 @@ process_key(struct touchpad_dispatch *touchpad,
> case BTN_FORWARD:
> case BTN_BACK:
> case BTN_TASK:
> - notify_button(device->seat,
> + notify_button(device->seat,
> time, e->code,
> e->value ? WL_POINTER_BUTTON_STATE_PRESSED :
> WL_POINTER_BUTTON_STATE_RELEASED);
> @@ -634,8 +654,7 @@ touchpad_process(struct evdev_dispatch *dispatch,
>
> switch (e->type) {
> case EV_SYN:
> - if (e->code == SYN_REPORT)
> - touchpad->event_mask |= TOUCHPAD_EVENT_REPORT;
> + process_syn(touchpad, device, e, time);
> break;
> case EV_ABS:
> process_absolute(touchpad, device, e);
> @@ -664,6 +683,32 @@ struct evdev_dispatch_interface touchpad_interface = {
> touchpad_destroy
> };
>
> +static void
> +touchpad_syn_drop_process(struct evdev_dispatch *dispatch,
> +struct evdev_device *device,
> +struct input_event *event,
> +uint32_t time)
> +{
> + if ((event->code != EV_SYN) || (event->code != SYN_REPORT))
> + return;
> +
> + if (device->dispatch->interface == &touchpad_syn_drop_interface)
> + device->dispatch->interface = &touchpad_interface;
> +
> + evdev_keys_state_sync(device, time);
> +}
> +
> +static void
> +touchpad_syn_drop_destroy(struct evdev_dispatch *dispatch)
> +{
> + free(dispatch);
> +}
> +
> +struct evdev_dispatch_interface touchpad_syn_drop_interface = {
> + touchpad_syn_drop_process,
> + touchpad_syn_drop_destroy
> +};
Re: [PATCH 05/18] fbdev: initialize yoffset of varinfo
Hi
On Fri, Jun 21, 2013 at 10:49 AM, mchalain [marc.chal...@gmail.com]
wrote:
> From: mchalain
>
> it initializes varinfo.yoffset. varinfo.yoffset has to
> point on the beginning of the video memory.
> The card uses this value to push on the screen a part of
> the video memory when this one is larger than the screen.
>
> ---
> weston/src/compositor-fbdev.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/weston/src/compositor-fbdev.c b/weston/src/compositor-fbdev.c
> index adfb67a..d2aee9b 100644
> --- a/weston/src/compositor-fbdev.c
> +++ b/weston/src/compositor-fbdev.c
> @@ -368,6 +368,11 @@ fbdev_query_screen_info(struct fbdev_output *output, int
> fd,
> return -1;
> }
>
> + if (varinfo.yoffset != 0) {
> + varinfo.yoffset = 0;
> + if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
> + return -1;
> + }
Why do you need this? It's unnecessary. We call FBIOPUT_VSCREENINFO
after fbdev_query_screen_info(), anyway. Furthermore, not all drivers
support panning even though the yoffset may be non-zero (you need
FBIOPUT_VSCREENINFO then).
I think you can just drop this here but keep the yoffset=0 below.
> return 1;
> }
>
> @@ -404,6 +409,7 @@ fbdev_set_screen_info(struct fbdev_output *output, int fd,
> varinfo.blue.length = 8;
> varinfo.blue.msb_right = 0;
>
> + varinfo.yoffset = 0;
Yep, this is definitely needed.
Regards
David
> /* Set the device's screen information. */
> if (ioctl(fd, FBIOPUT_VSCREENINFO, &varinfo) < 0) {
> return -1;
> --
> 1.7.9.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 1/2] compositor-drm: Cache the DPMS property on drm_output
Hi Ander
On Tue, Jun 4, 2013 at 3:24 PM, Ander Conselvan de Oliveira
wrote:
> From: Ander Conselvan de Oliveira
>
> This avoids one drmModeGetConnector() call every time the DPMS mode is
> set. That call can take hundreds of milliseconds due to DDC.
> ---
> src/compositor-drm.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 4222e57..27d4d02 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -145,6 +145,7 @@ struct drm_output {
> uint32_t connector_id;
> drmModeCrtcPtr original_crtc;
> struct drm_edid edid;
> + drmModePropertyPtr dpms_prop;
>
> int vblank_pending;
> int page_flip_pending;
> @@ -1054,6 +1055,8 @@ drm_output_destroy(struct weston_output *output_base)
> if (output->backlight)
> backlight_destroy(output->backlight);
>
> + drmModeFreeProperty(output->dpms_prop);
> +
> /* Turn off hardware cursor */
> drmModeSetCursor(c->drm.fd, output->crtc_id, 0, 0, 0);
>
> @@ -1365,23 +1368,12 @@ drm_set_dpms(struct weston_output *output_base, enum
> dpms_enum level)
> struct drm_output *output = (struct drm_output *) output_base;
> struct weston_compositor *ec = output_base->compositor;
> struct drm_compositor *c = (struct drm_compositor *) ec;
> - drmModeConnectorPtr connector;
> - drmModePropertyPtr prop;
>
> - connector = drmModeGetConnector(c->drm.fd, output->connector_id);
> - if (!connector)
> + if (!output->dpms_prop)
> return;
>
> - prop = drm_get_prop(c->drm.fd, connector, "DPMS");
> - if (!prop) {
> - drmModeFreeConnector(connector);
> - return;
> - }
> -
> - drmModeConnectorSetProperty(c->drm.fd, connector->connector_id,
> - prop->prop_id, level);
> - drmModeFreeProperty(prop);
> - drmModeFreeConnector(connector);
> + drmModeConnectorSetProperty(c->drm.fd, output->connector_id,
> + output->dpms_prop->prop_id, level);
> }
>
> static const char *connector_type_names[] = {
> @@ -1813,6 +1805,7 @@ create_output_for_connector(struct drm_compositor *ec,
> ec->connector_allocator |= (1 << output->connector_id);
>
> output->original_crtc = drmModeGetCrtc(ec->drm.fd, output->crtc_id);
> + output->dpms_prop = drm_get_prop(ec->drm.fd, connector, "DPMS");
Please also call this on VT_Enter(). Other sessions might disable
connectors and we need to detect that and refresh our state.
Otherwise, we end up with an outdated cache and disabled connector and
we will get errors on drmModeSetCrtc().
Regards
David
>
> /* Get the current mode on the crtc that's currently driving
> * this connector. */
> --
> 1.7.9.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: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Mon, May 27, 2013 at 12:35 PM, Peter Hutterer wrote: > On Fri, May 24, 2013 at 05:07:14PM +0200, David Herrmann wrote: > [...] >> >> This library is intended to solve the classification/detection >> >> problem. While the kernel evdev-interface provides us a bunch of >> >> information for each device, it doesn't provide any classification of >> >> the device (mostly because it would be unreliable). So libinputmapper >> >> as I see it is supposed to replace the heuristics that we currently >> >> have (KEY_A-KEY_Z => keyboard, REL_X/Y => mouse, ...) with a more >> >> user-controlled interface. >> >> >> >> So a *compositor* defines the type of devices, that it wants to >> >> support. As an example, it needs mouse+touchpad devices as >> >> mouse-input, keyboards as keyboard input. It then listens for all >> >> input hotplug events via udev, calls libinputmapper to provide tags >> >> for the devices and then checks, whether it's one of the devices that >> >> it wants. Client-side support is not involved, yet. >> > >> > ok, that makes sense to me and is a good idea. it's a combined version of >> > (formerly) udev's input_id tool and the Match* system that X has, in the >> > form of a library with simple adjustment based on textfiles. >> > >> > good. and sorry, I did somewhat tie all this in with the client side as >> > well, which is where the confusion came from. >> > >> > I think the tagging library will be quite private to the compositor >> > implementation (even if that means all compositors). in the X case, we have >> > evdev and the wacom driver for tablet devices since they're different >> > enough to basic tablets. I suspect something like that >> > may be required for wayland sooner or later. >> >> input_id+Match* seems to be a good description. That's what I had in >> mind. But I don't see a reason to keep it private to the compositor. >> The compositor is the #1 user of the library, but whatever API is used >> to forward events to a client, we shouldn't hide this source. We can >> save all other kinds of useful information in these files. A client >> could retrieve device-geometry information or other static data. >> I designed the configuration to allow a global database with local >> additions. So a compositor can have a different configuration than a >> client. But both have the same global base/fallback configuration. > > ok. the reason I assumed private is because you need to decide where the > level of abstraction sits and I think we don't think of it the same way > there. > > you can tag a device as tablet, but that doesn't tell you which driver to > use in the compositor to parse the data (see wacom example). so now the > compositor has another lookup table so it knows which module to load for > this device. this lookup table can either be duplicated across compositors, > or be moved into a library. and now you have your libinputmodulemapper on > top (well, on the side) of libinputmapper. I don't understand. What's wrong with linking device-TAGs to drivers in the compositor? So the compositor loads all drivers dynamically and each driver specifies which tags it supports. A new device is then assigned to the driver that currently is associated with the tag. If you want to overwrite that, add a "[driver]" section to the device-config/rule and use "bind = ". The compositor then needs to support the "[driver]" section and can see whether it should force-bind another driver than the default. Or even better, if you have multiple tags for tablets, like TAG_TABLET and TAG_WACOM_TABLET, you can define both on wacom tablets but only TAG_TABLET on other random tablets. Then bind the normal tablet/mouse/whatever driver to TAG_TABLET and your wacom driver to TAG_WACOM_TABLET. Of course, TAG_WACOM_TABLET then needs a higher priority than TAG_TABLET. This will work whether the wacom-driver is loaded or not. > likewise, as in another part of this thread: the compositor may not care > about the distinction between joystick/gamepad but the client may. so again > we have two different use-cases and mapping requirements here. Then the compositor just binds it's gaming-device-driver to (TAG_JOYSTICK | TAG_GAMEPAD). A client may use TAG_JOYSTICK or TAG_GAMEPAD separately. I don't see the problem here? >> > so the tagging library would have to tag a device not just as graphics >> > tablet but more as input module selection library. which again, means it's >> > a >>
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi On Thu, May 23, 2013 at 7:32 AM, Peter Hutterer wrote: > On Tue, May 21, 2013 at 04:30:03PM +0200, David Herrmann wrote: >> Hi Peter >> >> On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer >> wrote: >> > On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: >> >> Hi Peter >> >> >> >> On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer >> >> wrote: >> >> > On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: >> >> [..] >> >> >> So what is the proposed solution? >> >> >> My recommendation is, that compositors still search for devices via >> >> >> udev and use device drivers like libxkbcommon. So linux evdev handling >> >> >> is still controlled by the compositor. However, I'd like to see >> >> >> something like my libinputmapper proposal being used for device >> >> >> detection and classification. >> >> >> >> >> >> libinputmapper provides an "inmap_evdev" object which reads device >> >> >> information from an evdev-fd or sysfs /sys/class/input/input >> >> >> path, performs some heuristics to classify it and searches it's global >> >> >> database for known fixups for broken devices. >> >> >> It then provides "capabilities" to the caller, which allow them to see >> >> >> what drivers to load on the device. And it provides a very simple >> >> >> mapping table that allows to apply fixup mappings for broken devices. >> >> >> These mappings are simple 1-to-1 mappings that are supposed to be >> >> >> applied before drivers handle the input. This is to avoid >> >> >> device-specific fixup in the drivers and move all this to the >> >> >> inputmapper. An example would be a remapping for gamepads that report >> >> >> BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for >> >> >> backwards-compatibility reasons. The gamepad-driver can then assume >> >> >> that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and >> >> >> doesn't need to special case xbox360/etc. controllers, because they're >> >> >> broken. >> >> > >> >> > I think evdev is exactly that interface and apparently it doesn't work. >> >> > >> >> > if you want a mapping table, you need a per-client table because sooner >> >> > or >> >> > later you have a client that needs BTN_FOO when the kernel gives you >> >> > BTN_BAR >> >> > and you can't change the client to fix it. >> >> > >> >> > i.e. the same issue evdev has now, having a global remapping table just >> >> > moves the problem down by 2 years. >> >> > >> >> > a mapping table is good, but you probably want two stages of mapping: >> >> > one >> >> > that's used in the compositor for truly broken devices that for some >> >> > reason >> >> > can't be fixed in the kernel, and one that's used on a per-client >> >> > basis. and >> >> > you'll likely want to be able to overide the client-specific from >> >> > outside >> >> > the client too. >> >> >> >> IMHO, the problem with evdev is, that it doesn't provide device >> >> classes. The only class we have is "this is an input device". All >> >> other event-flags can be combined in whatever way we want. >> >> >> >> So like 10 years ago when the first gamepad driver was introduced, we >> >> added some mapping that was unique to this device (the device was >> >> probably unique, too). Some time later, we added some other >> >> gamepad-like driver with a different mapping (as it was probably a >> >> very different device-type, back then, and we didn't see it coming >> >> that this will become a wide-spread device-type). >> >> However, today we notice that a "GamePad" is an established type of >> >> device (like a touchpad), but we have tons of different mappings in >> >> the kernel for backwards-compatibility reasons. I can see that this >> >> kind of development can happen again (and very likely it _will_ happen >> >> again) and it will happen for all kinds of devices. >> >> >> &
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer wrote: > On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote: >> Hi Peter >> >> On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer >> wrote: >> > On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote: >> [..] >> >> So what is the proposed solution? >> >> My recommendation is, that compositors still search for devices via >> >> udev and use device drivers like libxkbcommon. So linux evdev handling >> >> is still controlled by the compositor. However, I'd like to see >> >> something like my libinputmapper proposal being used for device >> >> detection and classification. >> >> >> >> libinputmapper provides an "inmap_evdev" object which reads device >> >> information from an evdev-fd or sysfs /sys/class/input/input >> >> path, performs some heuristics to classify it and searches it's global >> >> database for known fixups for broken devices. >> >> It then provides "capabilities" to the caller, which allow them to see >> >> what drivers to load on the device. And it provides a very simple >> >> mapping table that allows to apply fixup mappings for broken devices. >> >> These mappings are simple 1-to-1 mappings that are supposed to be >> >> applied before drivers handle the input. This is to avoid >> >> device-specific fixup in the drivers and move all this to the >> >> inputmapper. An example would be a remapping for gamepads that report >> >> BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for >> >> backwards-compatibility reasons. The gamepad-driver can then assume >> >> that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and >> >> doesn't need to special case xbox360/etc. controllers, because they're >> >> broken. >> > >> > I think evdev is exactly that interface and apparently it doesn't work. >> > >> > if you want a mapping table, you need a per-client table because sooner or >> > later you have a client that needs BTN_FOO when the kernel gives you >> > BTN_BAR >> > and you can't change the client to fix it. >> > >> > i.e. the same issue evdev has now, having a global remapping table just >> > moves the problem down by 2 years. >> > >> > a mapping table is good, but you probably want two stages of mapping: one >> > that's used in the compositor for truly broken devices that for some reason >> > can't be fixed in the kernel, and one that's used on a per-client basis. >> > and >> > you'll likely want to be able to overide the client-specific from outside >> > the client too. >> >> IMHO, the problem with evdev is, that it doesn't provide device >> classes. The only class we have is "this is an input device". All >> other event-flags can be combined in whatever way we want. >> >> So like 10 years ago when the first gamepad driver was introduced, we >> added some mapping that was unique to this device (the device was >> probably unique, too). Some time later, we added some other >> gamepad-like driver with a different mapping (as it was probably a >> very different device-type, back then, and we didn't see it coming >> that this will become a wide-spread device-type). >> However, today we notice that a "GamePad" is an established type of >> device (like a touchpad), but we have tons of different mappings in >> the kernel for backwards-compatibility reasons. I can see that this >> kind of development can happen again (and very likely it _will_ happen >> again) and it will happen for all kinds of devices. >> >> But that's why I designed the proposal from a compositor's view >> instead of from a kernel's view. >> >> A touchpad driver of the compositor needs to know exactly what kind of >> events it gets from the kernel. If it gets wrong events, it will >> misbehave. As we cannot guarantee that all kernel drivers behave the >> same way, the compositor's touchpad driver needs to work around all >> these little details on a per-device basis. >> To avoid this, I tried to abstract the touchpad-protocol and moved >> per-device handling into a separate library. It detects all devices >> that can serve as a touchpad and fixes trivial (1-to-1 mapping) >> incompatibilities. This removes all per-device handling from the >> touchpad driver and it can expect all
