This device randomly decides that a touch is now a palm, based on
the moon phase, the user's starsign and possibly what the dog had for
breakfast. Since libinput assumes that a touchpad that labels a touch as palm
has reasons to do so, let's unassume this for this device by disabling that
axis alto
libinput 1.10.5 is now available. Only a few hardware-specific fixes, the
Logitech K400 has button debouncing disabled to avoid missing double-taps.
The Dell XPS13 L322X had the touchpad pressure ranges added to provide
better responsiveness. And the Lenovo T440, T450s and X280 laptops had the
trac
This adds a new protocol to negotiate server-side rendering of window
decorations for xdg-toplevels. This allows compositors that want to draw
decorations themselves to send their preference to clients, and clients that
prefer server-side decorations to request them.
This is inspired by a protocol
On Wed, Apr 18, 2018 at 03:53:31PM +0300, Pekka Paalanen wrote:
> On Wed, 18 Apr 2018 08:21:29 -0400
> Drew DeVault wrote:
>
> > Replying to everyone.
> >
> > On 2018-04-18 5:32 AM, Simon Ser wrote:
> > > I agree with Jonas here. Maybe we could add two fields:
> > >
> > > - "codename", restric
On Wed, Apr 18, 2018 at 11:32:09AM -0400, Simon Ser wrote:
> On April 18, 2018 1:05 PM, Jonas Ådahl wrote:
> > Since the issue is more of a race condition kind of issue, it might not
> > be easily reproducable with a demo client, but must be solved by coming
> > up with a type of negotiation that
On April 18, 2018 1:05 PM, Jonas Ådahl wrote:
> Since the issue is more of a race condition kind of issue, it might not
> be easily reproducable with a demo client, but must be solved by coming
> up with a type of negotiation that doesn't result in incorrect
> intermediate states for example the o
Hi,
On 18 April 2018 at 13:37, Pekka Paalanen wrote:
> On Wed, 18 Apr 2018 12:09:45 +0300 Pekka Paalanen wrote:
>> Sure, I'll see about adding that.
>
> looks like I would get into a bit of pickle in
> drm_pending_state_apply_atomic() if struct drm_output has heads_dirty
> flag.
>
> Currently th
If view is set to be entirely transparent,
there is no need to accumulate its damage.
This is an important optimization for
using view transparency. Because otherwise
transparent views are rendered like an
opaque view, and their pixel values
are set to 0 in fragment shader.
Signed-off-by: Emre Uc
On Wed, 18 Apr 2018 08:21:29 -0400
Drew DeVault wrote:
> Replying to everyone.
>
> On 2018-04-18 5:32 AM, Simon Ser wrote:
> > I agree with Jonas here. Maybe we could add two fields:
> >
> > - "codename", restricted to alphanumeric + hyphens characters (to reflect
> > the
> > current inform
On Wed, 18 Apr 2018 12:09:45 +0300
Pekka Paalanen wrote:
> On Thu, 12 Apr 2018 14:55:01 +0200
> Daniel Stone wrote:
>
> > On 16 February 2018 at 15:57, Pekka Paalanen wrote:
> > > For the attach on an enabled output to have an effect, we need to go
> > > through drmModeSetCrtc or ATOMIC_ALLO
Replying to everyone.
On 2018-04-18 5:32 AM, Simon Ser wrote:
> I agree with Jonas here. Maybe we could add two fields:
>
> - "codename", restricted to alphanumeric + hyphens characters (to reflect the
> current informal practice to name outputs like "VGA-1"), specified to be
> unique and pe
On Wed, Apr 18, 2018 at 07:49:12AM -0400, Simon Ser wrote:
> On April 18, 2018 10:28 AM, Jonas Ådahl wrote:
> > How do you imagine avoiding state transitions that don't result in
> > incorrect intermediate state? If a compositor changes the preferred
> > mode, does it wait some arbitrary time to s
On April 18, 2018 10:28 AM, Jonas Ådahl wrote:
> > I'm not sure it's a good idea to add decorations to non-toplevel surfaces. I
> > can't think of a use-case for popups. We don't know yet what kind of
> > xdg-surface will be added later, so I think we can't really design a
> > protocol
> > that w
On Tue, 10 Apr 2018 08:56:41 -0500
Derek Foreman wrote:
> On 2018-04-10 08:12 AM, Pekka Paalanen wrote:
> > On Sat, 24 Mar 2018 10:16:12 +
> > "Ray, Ian (GE Healthcare)" wrote:
> >
> >>> On 23 Mar 2018, at 19.16, Ray, Ian (GE Healthcare) wrote:
> >>>
> >>>
> On 23 Mar 2018, at
On April 18, 2018 9:57 AM, Jonas Ådahl wrote:
> Replying to both Pekka and Drew at the same time here:
>
> On Mon, Apr 16, 2018 at 11:14:51AM -0400, Drew DeVault wrote:
> > On 2018-04-16 2:57 PM, Jonas Ådahl wrote:
> > > I'd still like a bit more clarification about what to expect of this
> > >
On Tue, Apr 17, 2018 at 05:37:48PM -0400, Simon Ser wrote:
> (Re-sending the message because I forgot to reply to the list)
>
> On April 13, 2018 2:56 PM, Jonas Ådahl wrote:
> > Another thing to consider is whether non-toplevels ever want a similar
> > kind of protocol? It is not something we nee
On Thu, 12 Apr 2018 14:55:01 +0200
Daniel Stone wrote:
> On 16 February 2018 at 15:57, Pekka Paalanen wrote:
> > For the attach on an enabled output to have an effect, we need to go
> > through drmModeSetCrtc or ATOMIC_ALLOW_MODESET.
> >
> > Signed-off-by: Pekka Paalanen
> > ---
> > libweston/
On Thu, 12 Apr 2018 14:41:24 +0200
Daniel Stone wrote:
> On 16 February 2018 at 15:57, Pekka Paalanen wrote:
> > @@ -1863,7 +1869,7 @@ drm_output_apply_state_legacy(struct drm_output_state
> > *state)
> > }
> >
> > ret = drmModeSetCrtc(backend->drm.fd, output->cr
Replying to both Pekka and Drew at the same time here:
On Mon, Apr 16, 2018 at 11:14:51AM -0400, Drew DeVault wrote:
> On 2018-04-16 2:57 PM, Jonas Ådahl wrote:
> > I'd still like a bit more clarification about what to expect of this
> > string. What I'm trying to avoid is one compositor sending
On Thu, 12 Apr 2018 14:58:13 +0200
Daniel Stone wrote:
> Hi Pekka,
>
> On 12 April 2018 at 14:53, Pekka Paalanen wrote:
> > On Thu, 12 Apr 2018 15:37:43 +0300 Pekka Paalanen
> > wrote:
> >> On Thu, 12 Apr 2018 14:03:32 +0200 Daniel Stone
> >> wrote:
> >> > One thing I'm missing (possibl
On Mon, 16 Apr 2018 13:40:44 +1000
Peter Hutterer wrote:
> On Fri, Apr 13, 2018 at 10:51:37AM +0300, Pekka Paalanen wrote:
> >
> > I think the appropriate solution for me here is to check whether the
> > normalized value I expect to be in [0, 1] falls outside of the range,
> > and if so, I wil
On Mon, 16 Apr 2018 11:14:51 -0400
Drew DeVault wrote:
> On 2018-04-16 2:57 PM, Jonas Ådahl wrote:
> > I'd still like a bit more clarification about what to expect of this
> > string. What I'm trying to avoid is one compositor sending "eDP-1" while
> > another sends "Built-in Display". For examp
On Mon, 16 Apr 2018 08:40:52 -0400
Drew DeVault wrote:
> On 2018-04-16 10:53 AM, Pekka Paalanen wrote:
> > That's very clear, but is it precisely your intention? Would it make
> > more sense to define that the name does not change during the lifetime
> > of the wl_output global instead? That woul
23 matches
Mail list logo
