date:20140327

Re: weston: weston randr protocol for testing and configuration

2014-03-27 Thread Pekka Paalanen

On Thu, 27 Mar 2014 04:08:15 +
"Wang, Quanxian"  wrote:

> Hi, Pq
> 
> The information to identify the unique mode: width, height and refresh are 
> enough? Not enough in theory. But is enough in real world. I have checked 
> with xrandr. Read the following comment.
> 
> Welcome any comment for that.
> 
> Thanks 
> 
> >> +
> >> +
> >> +  
> >> +  Set the mode of output.
> >> +  
> >> +   >> +   summary="the output object"/>
> >> +  
> >> +  
> >> +  
> >
> >So this is the simple mode set request.
> >
> >Do you think width/height/refresh is really enough to identify a mode? I 
> >don't
> >think so. I think in the early days of X11 RandR, NVidia hit the same 
> >problem, and
> >started to expose fake refresh values, only to be able to distinguish modes 
> >that
> >were identical in width/height/refresh but still different in timings. Or 
> >actually I
> >think it was much more complicated than that, but this is the point in 
> >simple terms.
> >
> >So we need something else here to identify a mode.
> >
> >Check what kind of protocol GNOME uses, and how current RandR protocol works.
> [Wang, Quanxian] Hi, Pq
> Your understanding are right in theory. But in reality, it is barely 
> possible. Width and height could be easily same, not easy for refresh at the 
> same time. Currently in xrandr, they use mode name to identify one mode (for 
> example widthxheight_refresh). in xrandr process, I don't find they take mode 
> information to compare. Maybe I missed, but from xrandr parameters, there is 
> no such option. They just take width, height, refresh as mode name to 
> identify one mode. Sometimes, only width and height. If we want to fully 
> support one unique mode, all the mode information have to be compared. 
> (clock, hdisplay, hsync_start, hsync_end, htotal, vdisplay, vsync_start, 
> vsync_end, vtotal, flags). But it is not convenient. Sometime, user basically 
> don't know what hdisplay is at all. They just know widthxheight_refresh. My 
> idea is just take width, height, refresh as the unique id for mode. 
> 

I assume the X server has the database of modes. I cannot think of any
reason why the xrandr client would be comparing modes at all. Why did
you expect that? Isn't the name of a mode in RandR just an arbitrary
string (perhaps mapped to an XID)?

These were introduced in RandR 1.2 according to the xrandr man page. If
you are looking at RandR 1.1, it is not sufficient for distinguishing
custom modes.

Say, how will you separate a normal mode from a reduced-blanking mode?
They can have the same width, height, and refresh rate, but one works
while the other is not reliable. I have had such monitors before.

Of course, you have the choice to not support custom modes with custom
timings. Is your intention to support only custom modes with "standard"
timings, but not with custom timings? If so, which standard do you
pick? VESA CVT?


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

Re: [PATCH fullscreen-shell v5 18/18] Add a screen sharing plugin

2014-03-27 Thread Andrew Wedgbury


Hi Jason,

A few comments I have from trying out your fullscreen-shell changes:

On Tue, 18 Mar 2014, Jason Ekstrand wrote:


+static struct ss_seat *
+ss_seat_create(struct shared_output *so, uint32_t id)
+{
+ struct ss_seat *seat;
+
+ seat = zalloc(sizeof *seat);
+ if (seat == NULL)
+ return NULL;
+
+ weston_seat_init(&seat->base, so->output->compositor, "default");


It would be great if we could transfer the seat name from the parent seat. 
In the case of VNC or RDP this could identify the remote user.



+ seat->output = so;
+ seat->parent.seat = wl_registry_bind(so->parent.registry, id,
+  &wl_seat_interface, 1);
+ wl_list_insert(so->seat_list.prev, &seat->link);
+
+ wl_seat_add_listener(seat->parent.seat, &ss_seat_listener, seat);
+ wl_seat_set_user_data(seat->parent.seat, seat);
+
+ return seat;
+}



+static struct shared_output *
+shared_output_create(struct weston_output *output, int parent_fd)
+{
+   struct shared_output *so;
+   struct wl_event_loop *loop;
+   struct ss_seat *seat;
+   int epoll_fd;
+
+   so = zalloc(sizeof *so);
+   if (so == NULL)
+   goto err_close;
+
+   wl_list_init(&so->seat_list);
+ 
+	so->parent.display = wl_display_connect_to_fd(parent_fd);

+   if (!so->parent.display)
+   goto err_alloc;
+ 
+	so->parent.registry = wl_display_get_registry(so->parent.display);

+   if (!so->parent.registry)
+   goto err_display;
+   wl_registry_add_listener(so->parent.registry,
+®istry_listener, so);
+   wl_display_roundtrip(so->parent.display);
+   if (so->parent.shm == NULL) {
+   weston_log("Screen share failed: No wl_shm found\n");
+   goto err_display;
+   }
+   if (so->parent.fshell == NULL) {
+   weston_log("Screen share failed: "
+  "Parent does not support wl_fullscreen_shell\n");
+   goto err_display;
+   }
+   if (so->parent.compositor == NULL) {
+   weston_log("Screen share failed: No wl_compositor found\n");
+   goto err_display;
+   }
+
+   /* Get SHM formats */
+   wl_display_roundtrip(so->parent.display);
+   if (!(so->parent.shm_formats & (1 << WL_SHM_FORMAT_XRGB))) {
+   weston_log("Screen share failed: "
+  "WL_SHM_FORMAT_XRGB not available\n");
+   goto err_display;
+   }
+
+   so->parent.surface =
+   wl_compositor_create_surface(so->parent.compositor);
+   if (!so->parent.surface) {
+   weston_log("Screen share failed: %m");
+   goto err_display;
+   }
+
+   so->parent.mode_feedback =
+   _wl_fullscreen_shell_present_surface_for_mode(so->parent.fshell,
+ 
so->parent.surface,
+ so->parent.output,
+ 
output->current_mode->refresh);
+   if (!so->parent.mode_feedback) {
+   weston_log("Screen share failed: %m");
+   goto err_display;
+   }
+   
_wl_fullscreen_shell_mode_feedback_add_listener(so->parent.mode_feedback,
+   &mode_feedback_listener,
+   so);
+
+   loop = wl_display_get_event_loop(output->compositor->wl_display);
+
+   epoll_fd = wl_display_get_fd(so->parent.display);
+   so->event_source =
+   wl_event_loop_add_fd(loop, epoll_fd, WL_EVENT_READABLE,
+shared_output_handle_event, so);
+   if (!so->event_source) {
+   weston_log("Screen share failed: %m");
+   goto err_display;
+   }
+ 
+	/* Ok, everything's created.  We should be good to go */

+   wl_list_init(&so->shm.buffers);
+   wl_list_init(&so->shm.free_buffers);
+
+   so->output = output;
+   so->output_destroyed.notify = output_destroyed;
+   wl_signal_add(&so->output->destroy_signal, &so->output_destroyed);
+
+   so->frame_listener.notify = shared_output_repainted;
+   wl_signal_add(&output->frame_signal, &so->frame_listener);
+   output->disable_planes++;


I think you should only disable planes if the fullscreen_shell doesn't 
have the cursor_plane capability. In that case, there also needs to be a 
way to update the pointer surface on the parent seat. Although I think 
the difficulty may be in detecting when the pointer image changes - at 
least I remember that being a problem in my previous attempt at doing 
this.


I guess you also need a corresponding disable_planes-- when screen sharing
stops?


+   weston_output_damage(output);
+ 
+	return so;

+
+err_display:
+   wl_list_for_each(seat, &so->se

Re: weston: weston randr protocol for testing and configuration

2014-03-27 Thread Jasper St. Pierre

I don't think the user really knows what refresh is either.

I'm actually curious: is there a reason to ever expose different modes to
the user that have the same width/height but different timings? What's the
rationale for choosing one instead of the other? I know nothing about
display panels, keep in mind.

I'm also assuming a modern system here with a modern display panel, so no
saying "the refresh means the CRT updates faster and it's brighter and less
less flicker"


On Thu, Mar 27, 2014 at 6:35 AM, Pekka Paalanen  wrote:

> On Thu, 27 Mar 2014 04:08:15 +
> "Wang, Quanxian"  wrote:
>
> > Hi, Pq
> >
> > The information to identify the unique mode: width, height and refresh
> are enough? Not enough in theory. But is enough in real world. I have
> checked with xrandr. Read the following comment.
> >
> > Welcome any comment for that.
> >
> > Thanks
> >
> > >> +
> > >> +
> > >> +  
> > >> +  Set the mode of output.
> > >> +  
> > >> +   > >> +   summary="the output object"/>
> > >> +  
> > >> +  
> > >> +  
> > >
> > >So this is the simple mode set request.
> > >
> > >Do you think width/height/refresh is really enough to identify a mode?
> I don't
> > >think so. I think in the early days of X11 RandR, NVidia hit the same
> problem, and
> > >started to expose fake refresh values, only to be able to distinguish
> modes that
> > >were identical in width/height/refresh but still different in timings.
> Or actually I
> > >think it was much more complicated than that, but this is the point in
> simple terms.
> > >
> > >So we need something else here to identify a mode.
> > >
> > >Check what kind of protocol GNOME uses, and how current RandR protocol
> works.
> > [Wang, Quanxian] Hi, Pq
> > Your understanding are right in theory. But in reality, it is barely
> possible. Width and height could be easily same, not easy for refresh at
> the same time. Currently in xrandr, they use mode name to identify one mode
> (for example widthxheight_refresh). in xrandr process, I don't find they
> take mode information to compare. Maybe I missed, but from xrandr
> parameters, there is no such option. They just take width, height, refresh
> as mode name to identify one mode. Sometimes, only width and height. If we
> want to fully support one unique mode, all the mode information have to be
> compared. (clock, hdisplay, hsync_start, hsync_end, htotal, vdisplay,
> vsync_start, vsync_end, vtotal, flags). But it is not convenient. Sometime,
> user basically don't know what hdisplay is at all. They just know
> widthxheight_refresh. My idea is just take width, height, refresh as the
> unique id for mode.
> >
>
> I assume the X server has the database of modes. I cannot think of any
> reason why the xrandr client would be comparing modes at all. Why did
> you expect that? Isn't the name of a mode in RandR just an arbitrary
> string (perhaps mapped to an XID)?
>
> These were introduced in RandR 1.2 according to the xrandr man page. If
> you are looking at RandR 1.1, it is not sufficient for distinguishing
> custom modes.
>
> Say, how will you separate a normal mode from a reduced-blanking mode?
> They can have the same width, height, and refresh rate, but one works
> while the other is not reliable. I have had such monitors before.
>
> Of course, you have the choice to not support custom modes with custom
> timings. Is your intention to support only custom modes with "standard"
> timings, but not with custom timings? If so, which standard do you
> pick? VESA CVT?
>
>
> Thanks,
> pq
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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

Re: weston: weston randr protocol for testing and configuration

2014-03-27 Thread Pekka Paalanen

On Thu, 27 Mar 2014 08:31:34 -0400
"Jasper St. Pierre"  wrote:

> I don't think the user really knows what refresh is either.
> 
> I'm actually curious: is there a reason to ever expose different modes to
> the user that have the same width/height but different timings? What's the
> rationale for choosing one instead of the other? I know nothing about
> display panels, keep in mind.

This is not for users, the whole weston-randr protocol is for
developer and administrator tools for testing different modes without
having to restart Weston and edit a config file in between.

I cannot see a reason to offer the same mode with different timings
during normal operations, but it would be useful for the very kind of
experimentation that this protocol extension is designed for.

At least, as far as I have understood. How far this interface should go
is still unclear to me. If Quanxian wants to stick with RandR 1.1
features, i.e. no dynamic custom modelines, that's ok, though to me it
seems like losing a good part of the possible benefits.

> I'm also assuming a modern system here with a modern display panel, so no
> saying "the refresh means the CRT updates faster and it's brighter and less
> less flicker"

My 1600x1200 monitor, connected via DVI-D, was unstable, going black
once in a while when ran with a normal timings mode at 60 Hz. Switching
to reduced blanking mode made it stable and got rid of the random green
snow. Yes, you can blame the hardware being on its edge.

The refresh rate was exactly the same. The reduced blanking mode just
made the pixel clock a bit lower, enough to make the picture stable.


Thanks,
pq

> On Thu, Mar 27, 2014 at 6:35 AM, Pekka Paalanen  wrote:
> 
> > On Thu, 27 Mar 2014 04:08:15 +
> > "Wang, Quanxian"  wrote:
> >
> > > Hi, Pq
> > >
> > > The information to identify the unique mode: width, height and refresh
> > are enough? Not enough in theory. But is enough in real world. I have
> > checked with xrandr. Read the following comment.
> > >
> > > Welcome any comment for that.
> > >
> > > Thanks
> > >
> > > >> +
> > > >> +
> > > >> +  
> > > >> +  Set the mode of output.
> > > >> +  
> > > >> +   > > >> +   summary="the output object"/>
> > > >> +  
> > > >> +  
> > > >> +  
> > > >
> > > >So this is the simple mode set request.
> > > >
> > > >Do you think width/height/refresh is really enough to identify a mode?
> > I don't
> > > >think so. I think in the early days of X11 RandR, NVidia hit the same
> > problem, and
> > > >started to expose fake refresh values, only to be able to distinguish
> > modes that
> > > >were identical in width/height/refresh but still different in timings.
> > Or actually I
> > > >think it was much more complicated than that, but this is the point in
> > simple terms.
> > > >
> > > >So we need something else here to identify a mode.
> > > >
> > > >Check what kind of protocol GNOME uses, and how current RandR protocol
> > works.
> > > [Wang, Quanxian] Hi, Pq
> > > Your understanding are right in theory. But in reality, it is barely
> > possible. Width and height could be easily same, not easy for refresh at
> > the same time. Currently in xrandr, they use mode name to identify one mode
> > (for example widthxheight_refresh). in xrandr process, I don't find they
> > take mode information to compare. Maybe I missed, but from xrandr
> > parameters, there is no such option. They just take width, height, refresh
> > as mode name to identify one mode. Sometimes, only width and height. If we
> > want to fully support one unique mode, all the mode information have to be
> > compared. (clock, hdisplay, hsync_start, hsync_end, htotal, vdisplay,
> > vsync_start, vsync_end, vtotal, flags). But it is not convenient. Sometime,
> > user basically don't know what hdisplay is at all. They just know
> > widthxheight_refresh. My idea is just take width, height, refresh as the
> > unique id for mode.
> > >
> >
> > I assume the X server has the database of modes. I cannot think of any
> > reason why the xrandr client would be comparing modes at all. Why did
> > you expect that? Isn't the name of a mode in RandR just an arbitrary
> > string (perhaps mapped to an XID)?
> >
> > These were introduced in RandR 1.2 according to the xrandr man page. If
> > you are looking at RandR 1.1, it is not sufficient for distinguishing
> > custom modes.
> >
> > Say, how will you separate a normal mode from a reduced-blanking mode?
> > They can have the same width, height, and refresh rate, but one works
> > while the other is not reliable. I have had such monitors before.
> >
> > Of course, you have the choice to not support custom modes with custom
> > timings. Is your intention to support only custom modes with "standard"
> > timings, but not with custom timings? If so, which standard do you
> > pick? VESA CVT?
> >
> >
> > Thanks,
> > pq
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedeskto

Re: weston: weston randr protocol for testing and configuration

2014-03-27 Thread Jasper St. Pierre

I mean, I'm mostly talking about user configuration in the case of a
desktop, when the user wants to change the mode of the display.

Obviously, it would be best if we could detect hardware edge cases like
that where it's going on the fritz and showing a green tint automatically,
and simply not offer the user a broken mode in the first place, but I don't
want to get a scolding from Adam Jackson, so I'll shut up.


On Thu, Mar 27, 2014 at 9:05 AM, Pekka Paalanen  wrote:

> On Thu, 27 Mar 2014 08:31:34 -0400
> "Jasper St. Pierre"  wrote:
>
> > I don't think the user really knows what refresh is either.
> >
> > I'm actually curious: is there a reason to ever expose different modes to
> > the user that have the same width/height but different timings? What's
> the
> > rationale for choosing one instead of the other? I know nothing about
> > display panels, keep in mind.
>
> This is not for users, the whole weston-randr protocol is for
> developer and administrator tools for testing different modes without
> having to restart Weston and edit a config file in between.
>
> I cannot see a reason to offer the same mode with different timings
> during normal operations, but it would be useful for the very kind of
> experimentation that this protocol extension is designed for.
>
> At least, as far as I have understood. How far this interface should go
> is still unclear to me. If Quanxian wants to stick with RandR 1.1
> features, i.e. no dynamic custom modelines, that's ok, though to me it
> seems like losing a good part of the possible benefits.
>
> > I'm also assuming a modern system here with a modern display panel, so no
> > saying "the refresh means the CRT updates faster and it's brighter and
> less
> > less flicker"
>
> My 1600x1200 monitor, connected via DVI-D, was unstable, going black
> once in a while when ran with a normal timings mode at 60 Hz. Switching
> to reduced blanking mode made it stable and got rid of the random green
> snow. Yes, you can blame the hardware being on its edge.
>
> The refresh rate was exactly the same. The reduced blanking mode just
> made the pixel clock a bit lower, enough to make the picture stable.
>
>
> Thanks,
> pq
>
> > On Thu, Mar 27, 2014 at 6:35 AM, Pekka Paalanen 
> wrote:
> >
> > > On Thu, 27 Mar 2014 04:08:15 +
> > > "Wang, Quanxian"  wrote:
> > >
> > > > Hi, Pq
> > > >
> > > > The information to identify the unique mode: width, height and
> refresh
> > > are enough? Not enough in theory. But is enough in real world. I have
> > > checked with xrandr. Read the following comment.
> > > >
> > > > Welcome any comment for that.
> > > >
> > > > Thanks
> > > >
> > > > >> +
> > > > >> +
> > > > >> +  
> > > > >> +  Set the mode of output.
> > > > >> +  
> > > > >> +   > > > >> +   summary="the output object"/>
> > > > >> +  
> > > > >> +  
> > > > >> +  
> > > > >
> > > > >So this is the simple mode set request.
> > > > >
> > > > >Do you think width/height/refresh is really enough to identify a
> mode?
> > > I don't
> > > > >think so. I think in the early days of X11 RandR, NVidia hit the
> same
> > > problem, and
> > > > >started to expose fake refresh values, only to be able to
> distinguish
> > > modes that
> > > > >were identical in width/height/refresh but still different in
> timings.
> > > Or actually I
> > > > >think it was much more complicated than that, but this is the point
> in
> > > simple terms.
> > > > >
> > > > >So we need something else here to identify a mode.
> > > > >
> > > > >Check what kind of protocol GNOME uses, and how current RandR
> protocol
> > > works.
> > > > [Wang, Quanxian] Hi, Pq
> > > > Your understanding are right in theory. But in reality, it is barely
> > > possible. Width and height could be easily same, not easy for refresh
> at
> > > the same time. Currently in xrandr, they use mode name to identify one
> mode
> > > (for example widthxheight_refresh). in xrandr process, I don't find
> they
> > > take mode information to compare. Maybe I missed, but from xrandr
> > > parameters, there is no such option. They just take width, height,
> refresh
> > > as mode name to identify one mode. Sometimes, only width and height.
> If we
> > > want to fully support one unique mode, all the mode information have
> to be
> > > compared. (clock, hdisplay, hsync_start, hsync_end, htotal, vdisplay,
> > > vsync_start, vsync_end, vtotal, flags). But it is not convenient.
> Sometime,
> > > user basically don't know what hdisplay is at all. They just know
> > > widthxheight_refresh. My idea is just take width, height, refresh as
> the
> > > unique id for mode.
> > > >
> > >
> > > I assume the X server has the database of modes. I cannot think of any
> > > reason why the xrandr client would be comparing modes at all. Why did
> > > you expect that? Isn't the name of a mode in RandR just an arbitrary
> > > string (perhaps mapped to an XID)?
> > >
> > > These were introduced in RandR 1.2 according to the xrandr man page. I

Re: [PATCH libinput] test: add litest helper functions for creating uinput devices

2014-03-27 Thread Jonas Ådahl

On Thu, Mar 27, 2014 at 08:48:02AM +1000, Peter Hutterer wrote:
> Both functions accept a series of event types/codes tuples, terminated by -1.
> For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is used
> as a property to enable.
> 
> The _abs function als takes an array of absinfo, with absinfo.value
> determining the axis to change. If none are given, abs axes are initialized
> with default settings.
> 
> Both functions abort on failure, so the caller does not need to check the
> return value.
> 
> Example code for creating a rel device:
> 
> struct libevdev_uinput *uinput;
> struct input_id id = { ... };
> uinput = litest_create_uinput_device("foo", &id,
>  EV_REL, REL_X,
>  EV_REL, REL_Y,
>  EV_KEY, BTN_LEFT,
>INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
>  -1);
> libevdev_uinput_write_event(uinput, EV_REL, REL_X, -1);
> libevdev_uinput_write_event(uinput, EV_SYN, SYN_REPORT, 0);
> ..
> libevdev_uinput_destroy(uinput);

The problem with this approach is that its no longer possible to use the
litest_touch_down, litest_touch_up etc any more. Especially for touch
events thats an annoyance to reimplement in the test case. We could add
helpers for that but then we'd have double set of helpers for every kind
of event we want to test.

The way I'd want to use something like this is to create a fake device,
possibly with some special parameters, and then use it in the same way
I'd use a "normal" test device. I'd rather have a way to somehow create
a special fake device that can be operated in the same way using the
same functions as a "normal" fake device.

Jonas

> 
> Signed-off-by: Peter Hutterer 
> ---
>  test/litest-bcm5974.c   |  43 +++-
>  test/litest-generic-highres-touch.c |  34 +++---
>  test/litest-synaptics-st.c  |  37 +++
>  test/litest-synaptics.c |  43 +++-
>  test/litest-trackpoint.c|  32 +++---
>  test/litest-wacom-touch.c   |  33 ++
>  test/litest.c   |  89 
>  test/litest.h   |   9 ++
>  test/path.c | 207 
> 
>  9 files changed, 244 insertions(+), 283 deletions(-)
> 
> diff --git a/test/litest-bcm5974.c b/test/litest-bcm5974.c
> index 5a8ce8a..c76a892 100644
> --- a/test/litest-bcm5974.c
> +++ b/test/litest-bcm5974.c
> @@ -95,7 +95,6 @@ static struct litest_device_interface interface = {
>  void
>  litest_create_bcm5974(struct litest_device *d)
>  {
> - struct libevdev *dev;
>   struct input_absinfo abs[] = {
>   { ABS_X, 1472, 5472, 75 },
>   { ABS_Y, 1408, 4448, 129 },
> @@ -107,34 +106,24 @@ litest_create_bcm5974(struct litest_device *d)
>   { ABS_MT_TRACKING_ID, 0, 65535, 0 },
>   { ABS_MT_PRESSURE, 0, 255, 0 }
>   };
> - struct input_absinfo *a;
> - int rc;
> + struct input_id id = {
> + .bustype = 0x3,
> + .vendor = 0x5ac,
> + .product = 0x249,
> + };
>  
>   d->interface = &interface;
> -
> - dev = libevdev_new();
> - ck_assert(dev != NULL);
> -
> - libevdev_set_name(dev, "bcm5974");
> - libevdev_set_id_bustype(dev, 0x3);
> - libevdev_set_id_vendor(dev, 0x5ac);
> - libevdev_set_id_product(dev, 0x249);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_LEFT, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_FINGER, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_QUINTTAP, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOUCH, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_DOUBLETAP, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_TRIPLETAP, NULL);
> - libevdev_enable_event_code(dev, EV_KEY, BTN_TOOL_QUADTAP, NULL);
> -
> - ARRAY_FOR_EACH(abs, a)
> - libevdev_enable_event_code(dev, EV_ABS, a->value, a);
> -
> - rc = libevdev_uinput_create_from_device(dev,
> - LIBEVDEV_UINPUT_OPEN_MANAGED,
> - &d->uinput);
> - ck_assert_int_eq(rc, 0);
> - libevdev_free(dev);
> + d->uinput = litest_create_uinput_abs_device("bcm5974", &id,
> + ARRAY_LENGTH(abs),
> + abs,
> + EV_KEY, BTN_LEFT,
> + EV_KEY, BTN_TOOL_FINGER,
> + EV_KEY, BTN_TOOL_QUINTTAP,
> + EV_KEY, BTN_TOUCH,
> + EV_KEY, BTN_TOOL_DOUBLETAP,
> + EV_KEY, BTN_TOOL_T

[ANNOUNCE] libxkbcommon-0.4.1

2014-03-27 Thread Ran Benita

We've accumulated some changes and bug fixes, so here's a new release.

libxkbcommon 0.4.1
==

- Converted README to markdown and added a Quick Guide to the
documentation, which breezes through the most common parts of
xkbcommon.
Link: http://xkbcommon.org/doc/current/md_doc_quick-guide.html

- 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).

- 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

- The consumed modifiers for a key are now calculated similarly
to libX11. The previous behavior caused a bug where Shift would
not cancel an active Caps Lock.

- Make xkbcommon-x11 work with the keymap reported by the XQuartz
X server.

https://bugs.freedesktop.org/show_bug.cgi?id=75798

- Reduce memory usage during keymap compilation some more.

- New API:
xkb_state_key_get_consumed_mods()
xkb_state_key_get_utf8()
xkb_state_key_get_utf32()

- Deprecated API:
XKB_MAP_COMPILE_PLACEHOLDER, XKB_MAP_NO_FLAGS
use XKB_KEYMAP_NO_FLAGS instead.

- Bug fixes.

Tarballs:

git tag: xkbcommon-0.4.1

http://xkbcommon.org/download/libxkbcommon-0.4.1.tar.xz
MD5: b70f4ed97b6c9432dc956e4177f3336a libxkbcommon-0.4.1.tar.xz
SHA1: 38814e7edea16d032463b853490dda9040e5b1 libxkbcommon-0.4.1.tar.xz

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

Re: [ANNOUNCE] libxkbcommon-0.4.1

2014-03-27 Thread David Herrmann

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: [ANNOUNCE] libxkbcommon-0.4.1

2014-03-27 Thread Ran Benita

On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:
> Hi

Hi David

> 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?

First, the reason I added these functions is that
https://bugs.freedesktop.org/show_bug.cgi?id=75892 made it necessary, I
would otherwise like to avoid adding new API at this point. But given
the situation, I tried to make the best of it.

I only ignore multiple-keysyms for the utf32 function -- I only added
it to match the existing xkb_keysym_to_utf32() function. I don't think
it makes sense to encode multiple-keysyms into a UTF-32 string, nobody
uses it. A better name would be xkb_keysym_to_unicode_codepoint() or
whatever, but I wanted to keep the existing name.

For the utf8 function, it is handled correctly, and is actually much
easier to use for multiple-keysyms than the old function. It builds the
string internally and finally ensures it's valid UTF-8.

Another advantage of adding new functions is that existing users don't
break due to the new behavior, they must opt-in.

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.

> > - 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+)

Yes.

> 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.

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 :)

> 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).

A flag makes sense; I try to to add stuff when someone really needs it,
not preemptively. Btw, xkb_state_new() doesn't take a flags arg - argh.

But in general this stuff should be the default, we initially tried to
avoid these nonsensical US-centric behavior (let's say intentionally :),
but both the keymaps and existing users actually depend on them, like
the capitalization and Control thing (and they are also there in the
spec).

> 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
> expli

33 matches

Mail list logo