jadahl (Jonas Ådahl)
User

Projects

User Details

User Since
Apr 23 2015, 12:14 AM (173 w, 1 d)

E-mail: jadahl@gmail.com

IRC nick, Freenode and GIMPNet: jadahl

Taiwan, timezone UTC+8

Recent Activity

Mar 29 2017

jadahl added a comment to T11: Input serials are broken.

The serial counter cannot be different for pointer, keyboard and touch as serials as "input event" identifiers used to avoid grab races. For example xdg_popup.grab() takes a serial, and the compositor may use this to find if it matches any of the most recent grab serials by touch/pointer/keyboard. If touch/pointer/keyboard's serials are disjoint, we may end up with malfunctioning grab race avoidance.

Mar 29 2017, 8:01 AM · Weston

Mar 10 2017

jadahl created T7722: Adding/removing temporary globals is racy.
Mar 10 2017, 7:03 AM · Wayland
jadahl closed T55: Wayland thread-safe API and Mesa EGL as Closed.

This is fixed, and has landed in both wayland and mesa.

Mar 10 2017, 6:30 AM · Wayland
jadahl triaged T7656: beer o'clock as High priority.

Triaged; beer missing.

Mar 10 2017, 6:24 AM · libinput (test import)

Jan 6 2017

jadahl moved T7656: beer o'clock from not so important things to super-important things on the libinput (test import) board.
Jan 6 2017, 5:07 AM · libinput (test import)
jadahl moved T7286: Trackpoint speed lock from Backlog to unicorn related features on the libinput (test import) board.
Jan 6 2017, 5:07 AM · libinput (test import)
jadahl moved T7312: acceleration problem from Backlog to super-important things on the libinput (test import) board.
Jan 6 2017, 5:05 AM · libinput (test import)

Aug 9 2016

jadahl added a comment to D1261: libweston-desktop: Put the compositor in charge of the toplevel views.

FWIW, I'm fine with this approach. An alternative is to let shell.c call weston_view_create() and then have the API

void
weston_desktop_surface_add_view(struct weston_desktop_surface *desktop_surface,
                                struct weston_view *view);

and maybe even a

void
weston_desktop_surface_remove_view(struct weston_desktop_surface *desktop_surface,
                                   struct weston_view *view);

even though the remove function would do the same as weston_view_destroy() I guess.

Aug 9 2016, 5:05 AM · Weston

Feb 24 2016

jadahl added a comment to T10: Add surface filters to input interfaces (wl_pointer, wl_keyboard, wl_touch).

Not sure I see the point. If a surface doesn't want pointer or touch input, it sets an empty input region. Only "shell surfaces" normally receive keyboard focus, and they will most likely always want it as well. The exception is a tooltip surface, which shouldn't be able to receive keyboard focus, but that seems rather like something xdg_shell:y.

Feb 24 2016, 9:08 AM · Wayland

Feb 18 2016

jadahl edited the content of GSoC project ideas.
Feb 18 2016, 9:55 AM

Feb 2 2016

jadahl added a comment to T7216: wl_display_dispatch(_queue) documentation about thread safeness is probably wrong.

Marking this as fixed now, since the following patch is now merged:

Feb 2 2016, 2:12 AM · Wayland (test import)

Jan 26 2016

jadahl added a comment to T7306: NULL dereference in weston_pointer_send_frame with RDP backend.

(In reply to Laurentiu Nicola from comment #2)

Connecting with freerdp seems to work, at least with my patch applied.

Jan 26 2016, 1:13 AM · Weston (test import)

Jan 18 2016

jadahl added a comment to T7303: Xwayland crashes with SIGBUS when processing PutImage.

(In reply to Pekka Paalanen from comment #4)

(In reply to Jonas Ådahl from comment #2)
> One thing I noticed was that /run/user/1000/ was 100% full when SIGBUS was
> hit, but I couldn't see any error messages about failed allocation, but not
> sure that has anything to do with it.

I think this is the cause. For an explanation why a full fs causes a SIGBUS,
see:
http://cgit.freedesktop.org/wayland/wayland/commit/
?id=011b6954031a25de8d9eb39631b6837553bb3cfb

Can you somehow check if the target memory is indeed mmapped from that fs
and if so, how does the file get created? This would allow a graceful
failure at least.

Jan 18 2016, 10:42 AM · XWayland (test import)
jadahl added a comment to T7303: Xwayland crashes with SIGBUS when processing PutImage.

Seems like enabling glamor makes the issue go away.

Jan 18 2016, 7:01 AM · XWayland (test import)
jadahl added a comment to T7303: Xwayland crashes with SIGBUS when processing PutImage.

(In reply to Michel Dänzer from comment #1)

This might be a kernel DRM driver issue. Which driver are you using?

BTW, it looks like glamor isn't enabled in Xwayland. Does enabling it help?

Jan 18 2016, 4:31 AM · XWayland (test import)
jadahl created T7303: Xwayland crashes with SIGBUS when processing PutImage.
Jan 18 2016, 3:28 AM · XWayland (test import)

Jan 11 2016

jadahl added a comment to T7300: Create account to download code.

Hi. You don't need an SSH account to download any code; you can just download it anonymously, without any need for any kind of registration. Either you download releases in form of .tar.xz files, or you can clone the git repository if that is what you prefer.

Jan 11 2016, 9:23 AM · Wayland (test import)

Oct 28 2015

jadahl added a comment to T7265: xrandr screen rotation.

Hey. This is a compositor feature and not related to Wayland. weston supports it (check 'man weston.ini' and search for transform). GNOME plans to support it, but its not finished yet (see https://bugzilla.gnome.org/show_bug.cgi?id=745079 ).

Oct 28 2015, 2:12 AM · Wayland (test import)

Oct 12 2015

jadahl added a comment to T55: Wayland thread-safe API and Mesa EGL.

Have we decided on using the wl_proxy wrapper or are we still considering having the scanner generate 2x number of helper functions?

Oct 12 2015, 10:21 AM · Wayland
jadahl claimed T55: Wayland thread-safe API and Mesa EGL.
Oct 12 2015, 9:57 AM · Wayland

Oct 8 2015

jadahl added a comment to T7253: No pointer events on windows on only hot-plugged monitor.

Patch merged, so closing this one now.

Oct 8 2015, 12:56 AM · XWayland (test import)

Oct 7 2015

jadahl added a comment to T7254: weston segfault with broken client.

This http://patchwork.freedesktop.org/patch/61207/ patch fixes it.

Oct 7 2015, 6:45 AM · Weston (test import)

Oct 4 2015

jadahl created T7253: No pointer events on windows on only hot-plugged monitor.
Oct 4 2015, 7:24 AM · XWayland (test import)

Sep 17 2015

jadahl added a comment to T6869: Protocol: wl_buffer.release is racy.

(In reply to Pekka Paalanen from comment #9)

(In reply to Jonas Ådahl from comment #8)
> Ok, yes I see it now.(In reply to Pekka Paalanen from comment #7)
> (In reply to Pekka Paalanen from comment #5)
> > Client side reference counting, that is, for every committed attach there
> > will be a release, seems like the preferred solution to me at the moment.
>
> How do you expect the client to get the new semantics (one release per
> commit) or do you mean to change it for everyone?

For everyone, yes.

I would hope that attaching the same wl_buffer to multiple surfaces is rare
enough that we can get away with it. Committing the same wl_buffer to a
surface before waiting for a release or a frame callback is I hope equally
rare. (If you wait for frame callback, you're probably going to draw, so
using a busy buffer is a mistake to begin with. If you wait for a release,
there is no race.)

Since you cannot get the wl_buffer out of EGL, EGL should never hit a case
where the client-side reference count would be more than one.

Also judging by krh's comment, it was probably expected to work in refcount
manner to begin with, we (probably just me) just screwed up the spec and
Weston.

Bumping the wl_surface version for this is IMO a backup plan, in case we
can't just change the semantics for everyone.

For now, this is a quite theoretical race, which is why I think we can solve
this now. With Presentation queueing that would change, so this must be
solved before queueing can get further.

Sep 17 2015, 12:43 PM · Wayland (test import)
jadahl added a comment to T6869: Protocol: wl_buffer.release is racy.

Ok, yes I see it now.(In reply to Pekka Paalanen from comment #7)

(In reply to Jonas Ådahl from comment #6)
> Why can't we just let wl_buffer.release simply be a notification about the
> buffer being reusable

Because it has exactly the race explained in the description of this bug.
This example applies particular to Weston with gl-renderer and a client
using wl_shm.

Sep 17 2015, 12:06 PM · Wayland (test import)
jadahl added a comment to T6869: Protocol: wl_buffer.release is racy.

Why can't we just let wl_buffer.release simply be a notification about the buffer being reusable, meaning,

Sep 17 2015, 6:57 AM · Wayland (test import)

Sep 7 2015

jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.

(In reply to Boram from comment #11)

> All threads call wl_display_read_events() after returning from poll(), but
> only the last thread reads the data from the fd. That way we make sure all
> threads who called wl_display_prepare_read_queue() will come out of poll
> before we read the data.

In multi-thread application, looks we need to avoid to use
dispatch()/dipatch_queue(). And there might be no problem if every threads
call prepare_read(), poll() and read_events(). For toolkits to support
multi-thread, they also need to be fixed to use prepare_read/read_events, as
well as mesa Pekka Paalanen mentioned above.

To replace roundtrip()/dispatch()/dispatch_queue(), can wayland offer a new
convenient API which internally calls poll() and read_events()? i.e,
wl_display_poll_read()? It will be more convenient than calling poll() and
read_events() directly by each library.

Sep 7 2015, 8:12 AM · Wayland (test import)

Sep 3 2015

jadahl added a comment to T7216: wl_display_dispatch(_queue) documentation about thread safeness is probably wrong.

(In reply to Marek Chalupa from comment #3)

> If you call prepare + poll + read in thread A and
> wl_display_dispatch_queue() in another thread B (dispatching two different
> queues), the fd could become readable before wl_display_dispatch_queue()
> calls poll
> (http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.
> c#n1574) and whole prepare+read sequence could run before it, queing events
> into both queues. After prepare+read queued events, thread B goes to sleep
> in poll with events hanging in the queue.

Oh, wait, dispatching queue and increasing reader_count is atomical in
wl_display_dispatch_queue(), so the thread A should not events, so it should
probably work

Sep 3 2015, 8:42 AM · Wayland (test import)

Sep 2 2015

jadahl created T7223: Clipboard protocol requires keyboard.
Sep 2 2015, 3:13 AM · Wayland (test import)

Sep 1 2015

jadahl added a comment to T7219: Usage of timerfd_create and signalfd prevent porting to non-linux platforms.

(In reply to Pekka Paalanen from comment #6)

I suppose one more option would be to have libwayland-server depend on
http://libevent.org/ and implement our API with that in the back, but I
haven't looked how well that could work, and I don't know how people would
like libwayland-server growing a new dependency.

Sep 1 2015, 7:05 AM · Wayland (test import)

Aug 31 2015

jadahl added a comment to T7207: libinput keep open motion sensor input device.

(In reply to Bastien Nocera from comment #10)

(In reply to Jonas Ådahl from comment #9)
> Is it so that gdm/gnome-shell doesn't close the input device because mutter
> is missing this
> <https://git.gnome.org/browse/mutter/commit/
> ?id=7ce06928e24843c7f625616a526fa7bfc1e0bddb> patch?

Possibly. Did that get cherry-picked to stable releases (the gnome-3-16
branch)?

Aug 31 2015, 1:40 PM · libinput (test import)
jadahl added a comment to T7207: libinput keep open motion sensor input device.

Is it so that gdm/gnome-shell doesn't close the input device because mutter is missing this https://git.gnome.org/browse/mutter/commit/?id=7ce06928e24843c7f625616a526fa7bfc1e0bddb patch?

Aug 31 2015, 12:59 PM · libinput (test import)
jadahl added a comment to T7219: Usage of timerfd_create and signalfd prevent porting to non-linux platforms.

(In reply to Pekka Paalanen from comment #2)

I am scared to even think of what spawning a thread in libwayland-server
would cause.

An alternate proposal to this problem would be to deprecate the whole server
event loop implementation in Wayland. It obviously has never worked on BSDs,
so BSDs could start by compiling a version of libwayland-server which does
not have that API (or plug it with stubs).

But this is major design change. We would need to plan how to gracefully
deprecate the event loop API everywhere, and port all users to third party
event loop libraries. Therefore it requires a significant buy-in from the
community.

I recall Jasper saying that Gnome's compositor does not use the event loop
stuff of libwayland-server, because they already have their own. I wonder
what others do.

Aug 31 2015, 7:07 AM · Wayland (test import)

Aug 27 2015

jadahl added a comment to T7213: Wayland may have interface bug when multi-threads programing..

(In reply to Yujie Shen from comment #9)

(In reply to Jonas Ådahl from comment #8)
> (In reply to Yujie Shen from comment #7)
>
> It is a requirement by wl_display_prepare_read_queue() that to succeed the
> queue has to be empty and it needs to succeed in order to block the other
> threads from dispatching. You should put it before wl_surface_frame()
> though, because it is between wl_surface_frame() and wl_proxy_set_queue()
> the race can happen, and don't forget to call wl_display_cancel_read().
>
> Earlier today I wrote a summary about the known threading issues in the API.
> Please see bug T7217.
Thanks.
I know it is a requirement by wl_display_prepare_read_queue() .
I mean why it is designed as that, only the queue is empty then it block the
other
threads from dispatching. It seems that wl_display_prepare_read_queue can
also be designed as it still can block other threads from dispatching when
the queue is not empty.

Aug 27 2015, 6:38 AM · Wayland (test import)
jadahl added a comment to T7213: Wayland may have interface bug when multi-threads programing..

(In reply to Yujie Shen from comment #7)

(In reply to Jonas Ådahl from comment #6)
> Yujie: as indirectly stated by Pekka, my example was incomplete. You would
> also need to dispatch pending events before the
> wl_display_prepare_read(display) call. This makes it, ignoring error
> handling, more or less:
>
> wl_surface_attach();
> while (wl_display_prepare_read_queue(display, queue) < 0)
> wl_display_dispatch_queue_pending(display, queue);
> window->callback = wl_surface_frame(window->surface);
> wl_proxy_set_queue(window->callback,queue2);
> wl_callback_add_listener(window->callback, &frame_listener, window);
> wl_display_cancel_read(display);
> wl_surface_commit(window->surface);
>
> This has the side effect that events already in the queue will be always
> dispatched before the frame is requested. This may have unwanted effects, so
> please consider whether this is Ok in your architecture. If it is not, you
> need to make sure that the above code is done after all events on the queue
> has been dispatched.

Thanks for your kindly help.
By adding
>while (wl_display_prepare_read_queue(display, queue2) < 0)
> wl_display_dispatch_queue_pending(display, queue2);
>wl_surface_commit(window->surface);
it works in my case.
but, I still don't understand why it requires the wl_event_queue to be
empty??
I'm trying to summary the restrictions of wayland when multi-thread
programming.
May I know if you have any idea about it.

Aug 27 2015, 6:14 AM · Wayland (test import)
jadahl created T7217: Meta bug for libwayland-client threading issues.
Aug 27 2015, 2:33 AM · Wayland (test import)
jadahl created T7216: wl_display_dispatch(_queue) documentation about thread safeness is probably wrong.
Aug 27 2015, 2:32 AM · Wayland (test import)
jadahl created T7215: wl_display_roundtrip_queue() exposes the wl_proxy_set_queue() race.
Aug 27 2015, 2:32 AM · Wayland (test import)
jadahl created T7214: There is no way to cancel wl_display_dispatch(_pending) call without a server roundtrip.
Aug 27 2015, 2:31 AM · Wayland (test import)

Aug 26 2015

jadahl added a comment to T7213: Wayland may have interface bug when multi-threads programing..

Yujie: as indirectly stated by Pekka, my example was incomplete. You would also need to dispatch pending events before the wl_display_prepare_read(display) call. This makes it, ignoring error handling, more or less:

Aug 26 2015, 2:48 AM · Wayland (test import)

Aug 25 2015

jadahl added a comment to T7213: Wayland may have interface bug when multi-threads programing..

(In reply to Yujie Shen from comment #3)

(In reply to Jonas Ådahl from comment #2)
> Hi and thanks for the report. This seems to be a duplicate of bug T7194, so
> closing this one. The problem can be worked around by using the current API
> to block dispatching on other threads (see the last paragraph of (omment 2
> of bug T7194 https://bugs.freedesktop.org/show_bug.cgi?id=T7194#c2. You
> will need this until we decide what API we want to introduce fix the issue
> properly.
>
> * This bug has been marked as a duplicate of bug T7194 *

Thank you.
But,this bug is totally different from bug T7194.
Bug T7194 reports a bug that 2 threads polling on same display fd in both
threads.
My bug,namely Bug T7213,reports a bug that a wl_proxy's property is still
being modifying in a thread,while another thread may have sent it to server.
Please kindly check the attachment"wayland multi-threads interface bug"again.

Aug 25 2015, 8:16 AM · Wayland (test import)
jadahl added a comment to T7213: Wayland may have interface bug when multi-threads programing..

Hi and thanks for the report. This seems to be a duplicate of bug T7194, so closing this one. The problem can be worked around by using the current API to block dispatching on other threads (see the last paragraph of (omment 2 of bug T7194 https://bugs.freedesktop.org/show_bug.cgi?id=T7194#c2. You will need this until we decide what API we want to introduce fix the issue properly.

Aug 25 2015, 7:18 AM · Wayland (test import)
jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.
  • Bug T7213 has been marked as a duplicate of this bug. ***
Aug 25 2015, 7:18 AM · Wayland (test import)

Jul 24 2015

jadahl added a comment to T7187: [bug] Can't write i and ı at turkish keyboard..

(In reply to Arda Ünlü from comment #8)

Why nobody cares?

Jul 24 2015, 10:05 AM · Wayland (test import)

Jul 21 2015

jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.

(In reply to Boram from comment #7)

> I still don't understand what you mean by "the kernel may not wake up the
> thread" if it refers to a different issue than the two mentioned above.

When A thread is polling on a display fd and B thread is polling on the same
display fd, if a server sends messages, sometimes only one thread(Let's say
it is B thread) awakes and reads all events so fast. Then A thread still is
in the polling status and can't awake. Even if B thread reads and queue all
events into corresponding queue_lists, the events of A thread's queue_list
can't be handled because A thread is still in sleep.

Jul 21 2015, 3:08 AM · Wayland (test import)

Jul 9 2015

jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.

(In reply to Boram from comment #1)

Created attachment 117011 [details]
simple test application to reproduce this bug

Jul 9 2015, 2:57 AM · Wayland (test import)
jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.

(In reply to Jonas Ådahl from comment #2)

(In reply to Boram from comment #0)
> Created attachment 117010 [details]
> simple test application to reproduce this bug

Please attach the source code for the test application instead of the binary
(I only see garbage when opening the attachment in the browser).

Jul 9 2015, 2:53 AM · Wayland (test import)
jadahl added a comment to T7194: Setting a queue on a wl_proxy is racy if some other thread is dispatching the default queue.

(In reply to Boram from comment #0)

Created attachment 117010 [details]
simple test application to reproduce this bug

Jul 9 2015, 2:52 AM · Wayland (test import)

Jul 3 2015

jadahl added a comment to T7193: Requesting New Account.

(In reply to Jin Li from comment #3)

Hi Jonas,
Basically, I want to join the event of
https://bugs.freedesktop.org/show_bug.cgi?id=T7193, which requests an
account to edit wiki page of
http://www.x.org/wiki/Events/XDC2015/Attendees/, that's how it ends up with
requesting this account.
Or if there is any other way to apply to this event without creating this
account, that would be good too.
Thanks,
Frank

Jul 3 2015, 2:35 AM · Wayland (test import)
jadahl added a comment to T7193: Requesting New Account.

Are you sure an fd.o account is what you need? You more or less only need it to push changes, which the maintainers are the ones who do. If you are looking to contribute patches to the Wayland project (which you filed this bug against), there is no need for this type of account; what you do is subscribe to the mailing list and post patches using git-send-email. You can read more about it here: http://cgit.freedesktop.org/wayland/wayland/tree/doc/Contributing

Jul 3 2015, 1:48 AM · Wayland (test import)

Jun 24 2015

jadahl added a comment to T7187: [bug] Can't write i and ı at turkish keyboard..

(In reply to İbrahim Yağız Bayazit from comment #2)

(In reply to Jonas Ådahl from comment #1)
> How do you run Wayland? Are you testing with weston? Or do you use GNOME's
> Wayand session? In what clients does the issue happen? More information
> about your issue is needed to get an idea of what and where the problem
> might be.

I use gnome's wayland session. it happened in gdm and gnome desktop. I'm
sorry, i'm not a proffesional linux user. If you need more information just
tell mi the command. I will send you information.

Jun 24 2015, 11:10 AM · Wayland (test import)
jadahl added a comment to T7187: [bug] Can't write i and ı at turkish keyboard..

How do you run Wayland? Are you testing with weston? Or do you use GNOME's Wayand session? In what clients does the issue happen? More information about your issue is needed to get an idea of what and where the problem might be.

Jun 24 2015, 5:31 AM · Wayland (test import)

May 25 2015

jadahl added a comment to T7163: gtk3-demo crashes run with wayland backend, wl_display invalid argument.

(In reply to Mark Yao from comment #4)

I've downgrade the gtk+ to 3.16.3, but same error again.

May 25 2015, 1:37 AM · Wayland (test import)

May 22 2015

jadahl added a comment to T7163: gtk3-demo crashes run with wayland backend, wl_display invalid argument.

(In reply to Mark Yao from comment #2)

(In reply to Jonas Ådahl from comment #1)
> You are reporting a crash in gtk3-demo, but this it the freedesktop.org bug
> tracker. Crashes in gtk3-demo should be reported it to bugs.gnome.org.
>
> Anyhow, the crash you are seeing is a version mismatch between the unstable
> xdg_shell of version 4 in weston 1.7, and the unstable xdg_shell of version
> 5 in gtk+ 3.17. If you upgrade to the latest RC (released a few days ago) of
> wayland/weston they will have the same version, or downgrade gtk to some
> earlier version that shipped with xdg_shell unstable version 4.

Sorry for bad place to report the bug.

May 22 2015, 8:20 AM · Wayland (test import)
jadahl added a comment to T7163: gtk3-demo crashes run with wayland backend, wl_display invalid argument.

You are reporting a crash in gtk3-demo, but this it the freedesktop.org bug tracker. Crashes in gtk3-demo should be reported it to bugs.gnome.org.

May 22 2015, 7:50 AM · Wayland (test import)

May 19 2015

jadahl added a comment to T7149: The mouse movements hang again and again..

If it's in gnome-shell you are seeing this, then this is probably the bug you are looking for: https://bugzilla.gnome.org/show_bug.cgi?id=745032

May 19 2015, 9:14 AM · Wayland (test import)

Apr 23 2015

jadahl updated subscribers of T11: Input serials are broken.
Apr 23 2015, 12:28 AM · Weston

Mar 28 2015

jadahl added a comment to T6870: Implement wl_probe, or something similar.

(In reply to x414e54 from comment #5)

(In reply to Pekka Paalanen from comment #4)
> (In reply to x414e54 from comment #3)
> > I prefer just being able to give the compositor a hint of what it should do
> > if it does not fit. Something like flip-x, flip-y, resize-w, resize-h,
> > nothing, scale parent surface.
> >
> > Though I think compositors will already automatically do some of this
> > depending on if it is a popup or child/transient surface.
> >
> > Probing does not make sense as if your surface is full-screen on one output
> > and normal on another output you would have to place the sub-surface inside
> > the main surface on all outputs even if it would be fine in the correct
> > position on the non full-screen output.
> >
> > If you give the compositor a hint and let it take care of it then it can
> > place it differently on different outputs.
>
> Sorry, but I don't think any of that makes sense.
>
> Menus usually want to be aligned somehow to some widget (of which the
> compositor has no knowledge of at all) like a menu-bar "button". The
> compositor does not have the knowledge to reposition the surface to keep the
> GUI aligments that the application toolkit wants to have. I suppose you
> could remedy that by giving the compositor the rect around which the popup
> should be aligned, but that's getting comlicated and moves some of the popup
> placement policy into the compositor, away from the toolkit.
>
> Resize would be basically the same as probe, except you'd probably get
> visual flicker. Probing is simpler. Scaling wouldn't work at all, because it
> would mess up the GUI scale and visual appearance.

The popup placement should be up to the compositor.
Otherwise you have situations where the compositor resizes/moves the parent,
or popup or even the display is resized
and the popup has not moved/closed/changed, which looks really stupid.
You would have to constantly call these probe events in a loop and update
the popup position.

Mar 28 2015, 4:36 AM · Wayland (test import)

Feb 3 2015

jadahl added a comment to T7093: subsurface protocol is inconsistent regarding immediate commit vs deferred commit.

Its not whether the example is reasonable or not, its just about what the spec dictates, and what implementations (server side) should do. I believe what makes most sense is to correct the wording to not require an explicit parent wl_surface.commit. I'd believe that'd break least things, and it is in line with the original idea; but my concern was more whether we can "fix bugs" in the spec this way?

Feb 3 2015, 10:13 AM · Wayland (test import)
jadahl added a comment to T7093: subsurface protocol is inconsistent regarding immediate commit vs deferred commit.

Ah, right, the position should be considered part of the parents surface, true. The issue that exists is though that the protocol explicitly says "on wl_surface.commit", which is not necessarily the same time that the parent surface gets its content updated. AFAIU the content of a surface is applied either on

Feb 3 2015, 8:53 AM · Wayland (test import)

Jan 29 2015

jadahl created T7093: subsurface protocol is inconsistent regarding immediate commit vs deferred commit.
Jan 29 2015, 3:45 AM · Wayland (test import)

Jan 15 2015

jadahl added a comment to T7092: Notification about config changes.

An event seems far better than polling to me.

Jan 15 2015, 6:32 AM · libinput (test import)

Jan 14 2015

jadahl added a comment to T7090: Request for ssh access.

You don't need ssh access for contributing to weston. Just send the patches to the mailing list. Please read http://cgit.freedesktop.org/wayland/wayland/tree/doc/Contributing for more detailed desciption of how.

Jan 14 2015, 9:15 AM · Weston (test import)

Dec 11 2014

jadahl added a comment to T7057: RFE: absolute mode for chinese character input on a touchpad.

Moving both conversations (this and Bug T7078) here: To use wl_touch we'd have to be able to wl_seat.get_touch in order to get such a device, so you mean that the hand writing client would ask for this feature some how and at that time the touchpad would stop being a touchpad and instead advertise itself as a wl_touch device? Should it only do that to that given client then, and what happens when the touch mode is disabled?

Dec 11 2014, 1:33 AM · libinput (test import)

Dec 10 2014

jadahl added a comment to T7078: No capability detection events.

Why is a touchpad changed into being able to output absolute coordinates? Why isn't that known to begin with? It doesn't sound like Bug T7057 would need change the feature matrix of a touchpad after adding but more making use of data discarded when abstracting the touchpad into a generic pointer device. Or am I missing something here?

Dec 10 2014, 9:46 AM · libinput (test import)
jadahl added a comment to T7057: RFE: absolute mode for chinese character input on a touchpad.

Sounds like this needs Wayland protocol as well, as wl_touch is in surface coordinates, while it sounds like this feature would need something more output surface independent. Pretty much somewhere between wl_touch and wl_tablet?

Dec 10 2014, 9:43 AM · libinput (test import)

Dec 9 2014

jadahl added a comment to T7078: No capability detection events.

Long ago there was such an event, but I think we decided to remove it because there was no use case where the capabilities were not known directly. The commit

Dec 9 2014, 7:26 AM · libinput (test import)

Nov 1 2014

jadahl added a comment to T7054: wl_fixed is not precise enough for high dpi mice.

(In reply to Derek Foreman from comment #3)

Libinput until 58e0fe270 was accidentally rounding some data internally, but
now as far as I can tell it's weston.

Pointer-lock is what a game would use to get "raw" mouse data? I think
there's a question as to whether that will be normalized at all by libinput

  • it may be the case that it'll come out the other side entirely on the left of the radix point, and this problem doesn't actually exist there.
Nov 1 2014, 4:27 PM · Weston (test import)
jadahl added a comment to T7054: wl_fixed is not precise enough for high dpi mice.

(In reply to Pekka Paalanen from comment #1)

Can we fix this by just changing from wl_fixed_t type to double in Weston
for computing and storing the pointer location, or does the rounding to zero
happen already in libinput?

Nov 1 2014, 1:03 PM · Weston (test import)

Oct 4 2014

jadahl added a comment to T7032: Can't play FPS games with Xwayland EG CS:GO Etc.

This most likely has to do with the lack of pointer warp support. Adding pointer locking bug as a blocker for this one, as it might be possible to implement warping support in Xwayland using the pointer lock protocol.

Oct 4 2014, 9:21 AM · XWayland (test import)

Sep 17 2014

jadahl added a comment to T7027: Pointer locking protocol.

A follow up to the previous RFC posted here: http://lists.freedesktop.org/archives/wayland-devel/2014-September/017318.html

Sep 17 2014, 7:41 PM · Wayland (test import)
jadahl created T7027: Pointer locking protocol.
Sep 17 2014, 7:38 PM · Wayland (test import)

Sep 9 2014

jadahl added a comment to T7005: USB mouse doesn't register slow movements to the right or down in Gnome on Wayland.

Thanks for the bug report, however the bug you are describing is in clutter. Could you open a bug in the GNOME bug tracker on the clutter product and assign it to me?

Sep 9 2014, 8:07 PM · libinput (test import)

Aug 14 2014

jadahl added a comment to T6976: fails to compile due to a hardcoded "-static" LDFLAG.

The thing is that the tools are built statically deliberately to simplify debugging, so not sure I just want to apply them without understanding the reason for why it fails. Otherwise we could add a switch to configure that disables the tools or builds them as non-statics.

Aug 14 2014, 6:16 AM · libinput (test import)

Aug 11 2014

jadahl added a comment to T6976: fails to compile due to a hardcoded "-static" LDFLAG.

I cannot reproduce this issue here. Both libevdev and libinput have "log_msg" functions indeed, but none are exported and I don't get this clash. What compiler version are you using and do you have any other configuration?

Aug 11 2014, 7:18 PM · libinput (test import)

Apr 12 2014

jadahl added a comment to T6892: Weston does not handle LIBINPUT_EVENT_TOUCH_FRAME (log spam).

Seems to have missed posting the patch hooking up frame events to the list. I just sent it now:
http://lists.freedesktop.org/archives/wayland-devel/2014-April/014205.html

Apr 12 2014, 7:41 AM · Weston (test import)

Oct 30 2013

jadahl added a comment to T6746: [bug] Multiple cursors appear when udev rules for seats are applied.

Hmm. Is it that it doesn't get reset because plugging it in doesn't call the init t(In reply to comment #4)

(In reply to comment #3)
> Kristian, you seem to have pushed the grab fixes to master. Should they be
> on 1.3 as well?

Yeah, they should. I was testing with an external touch screen and
unplugging the touchscreen (just the usb input device, not the output) and
even with your patches, the touch code has the same problem: plugging the
touch screen back in doesn't work. The problem seems to be that the num_tp
is in weston_seat and doesn't get reset when you remove the last touch
screen, but when I looked closer, it looks like we keep the weston_touch
struct around event when we unplug the last touch device.

Oct 30 2013, 9:06 PM · Weston (test import)

Oct 29 2013

jadahl added a comment to T6746: [bug] Multiple cursors appear when udev rules for seats are applied.

Kristian, you seem to have pushed the grab fixes to master. Should they be on 1.3 as well?

Oct 29 2013, 9:36 AM · Weston (test import)

Oct 17 2013

jadahl added a comment to T6746: [bug] Multiple cursors appear when udev rules for seats are applied.

This patch series fixes this bug: http://lists.freedesktop.org/archives/wayland-devel/2013-October/011528.html

Oct 17 2013, 9:05 PM · Weston (test import)

Mar 15 2013

jadahl added a comment to T6647: Wayland client (c++) crashes in event handler with a 'n' argument.

Could you try to see if you can reproduce it with this patch applied? http://lists.freedesktop.org/archives/wayland-devel/2013-March/007830.html

Mar 15 2013, 12:56 PM · Wayland (test import)

Mar 9 2013

jadahl added a comment to T6617: weston-desktop-shell crashed with SIGSEGV in ffi_call_unix64().

Can you try again with this patch applied? http://lists.freedesktop.org/archives/wayland-devel/2013-March/007830.html

Mar 9 2013, 12:24 PM · Weston (test import)

Mar 7 2013

jadahl added a comment to T6633: wayland-client.c:dispatch_event() dereferences proxy after free.

This patch fixes the warning when using scan-build from llvm trunk as of today:
http://lists.freedesktop.org/archives/wayland-devel/2013-March/007811.html

Mar 7 2013, 10:34 PM · Wayland (test import)
jadahl added a comment to T6640: Weston freezes system when switching back to its VT after leaving it for a while.

Seems to be some permission issue, looking at the following part of the log:

Mar 7 2013, 3:29 PM · Weston (test import)

Feb 24 2013

jadahl added a comment to T6633: wayland-client.c:dispatch_event() dereferences proxy after free.

Even though the static analyzer cought this, it can never happen in practice. This is because for a proxy object to reach reference count zero the owner must destroy it using wl_proxy_destroy(). This has the side effect of adding the WL_PROXY_FLAG_DESTROYED flag, which would hit the

Feb 24 2013, 8:59 AM · Wayland (test import)

Jan 4 2013

jadahl added a comment to T6613: [Wayland] queue-test test failed on ppc64.

Looking at the output you provided, the problem seems to be in the server process. Note the "signal 11, fail" i.e. "segmentation fault" message. The queue test consists of two processes; the server process, and the forked client process. It looks like the server process is the one that crashes, resulting in no registry objects being transmitted and counter not reaching 2 when it gets the EPIPE error when reading the socket.

Jan 4 2013, 5:11 PM · Wayland (test import)
jadahl added a comment to T6613: [Wayland] queue-test test failed on ppc64.

It seems so yes.

Jan 4 2013, 11:11 AM · Wayland (test import)
jadahl added a comment to T6613: [Wayland] queue-test test failed on ppc64.

So queue dispatching fails for some reason. You should be able to check errno for why something failed. Could be a broken pipe or something because the server part crashed. I don't have access to any ppc64 hardware so I cannot debug this myself.

Jan 4 2013, 10:38 AM · Wayland (test import)
jadahl added a comment to T6613: [Wayland] queue-test test failed on ppc64.

It looks like wl_display_roundtrip() returns before it receives the done event. As of 1.0.3 the only way this can happen is if an error occurs when dispatching the queue. Could you test adding a check to the return value of wl_display_roundtrip() before the assert that fails and check if it is != -1?

Jan 4 2013, 8:33 AM · Wayland (test import)

Nov 11 2012

jadahl added a comment to T6600: [regression] Weston event-test unit test failure.

I did some reseach on this and it seems to be three issues that needs to be fixed.

Nov 11 2012, 3:37 PM · Weston (test import)

Oct 22 2012

jadahl added a comment to T6587: [bug] Menu options are highlighted when mouse is off of the menu.

Can you verify your version of weston has this commit: http://cgit.freedesktop.org/wayland/weston/commit/?id=f461eee2b0bc99e2d444544f9cb3d9e21200595d as it fixed this issue for me?

Oct 22 2012, 9:12 PM · Weston (test import)

Oct 8 2012

jadahl added a comment to T6577: window menu mouse handling not working properly.

This[0] patch fixes the issue when menu items get selected while moving the pointer around on the parent surface.

Oct 8 2012, 7:24 AM · Weston (test import)