If the kernel sends us a button press for a button that is thought to be down
we have lost track of the state of the button. Ignore the button press event,
in the hope that the next release makes things right again.
A release event may be masked if another process grabs the device for some
period
There is already this paragraph added to xdg_toplevel:
+ Unmapping an xdg_toplevel means that the surface cannot be shown
+ by the compositor until it is explicitly mapped again.
+ All active operations (e.g., move, resize) are canceled and all
+ attributes (e.g. title, state,
Then I'd like some stronger wording in this patch that dictates that
unmapping and remapping a surface by either destroying the xdg_surface or
attaching a NULL buffer should be indistinguishable. No "hidden state",
either accessible or inaccessible to the app (such as stacking order,
window positio
On Thu, Jul 13, 2017 at 03:50:56PM +0200, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> > Dear All,
> >
> > I am looking for an solution to have early smooth splashscreen on the
> > Linux system with Weston and drm-backend.
> >
> > I tried showing splashscreen using
Hi Matt,
On 17 July 2017 at 20:39, Matt Hoosier wrote:
> Also beware that the DRM backend of Weston will aggressively set the mode
> before you have any chance to paint user-defined content of your own in a
> Wayland client program. So there will still be some window of time during
> which your e
I'm finding that it would be useful for shells implemented against
libweston-desktop to be able to know when the application's title or app-id
changes. Right now, that information is swallowed up inside the internal
logic.
Would a patch exporting changes to title or app_id be welcome? If so, do
yo
On Fri, Jul 14, 2017 at 8:56 AM, Daniel Vetter wrote:
> On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote:
> > On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter
> wrote:
> > > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil
> wrote:
> > >> Dear All,
> > >>
> > >> I am looking for an solutio
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
This approach here is the si
