On Thu, Apr 19, 2018 at 5:19 AM, Peter Hutterer
wrote:
> 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,
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses"
On 2018-04-19 09:01 AM, Derek Foreman wrote:
> From: Dipen Somani
>
> commit 3cddb3c692acd3536a7cc8542a29f0cc3c0ac3d6 casted len to an
> unsigned value to compare to sizeof results. However,
> wl_connection_read() can fail, setting errno to EAGAIN and returning
> a value of -1.
>
> When cast to
From: Dipen Somani
commit 3cddb3c692acd3536a7cc8542a29f0cc3c0ac3d6 casted len to an
unsigned value to compare to sizeof results. However,
wl_connection_read() can fail, setting errno to EAGAIN and returning
a value of -1.
When cast to an unsigned type this leads to a loop condition of true
when
From: Pekka Paalanen
For the attach on an enabled output to have an effect, we need to go
through drmModeSetCrtc or ATOMIC_ALLOW_MODESET.
v9:
- Add another XXX comment.
Signed-off-by: Pekka Paalanen
Acked-by: Derek Foreman
---
libweston/compositor-drm.c | 18 ++
1 file change
From: Pekka Paalanen
If we are processing a connector that does not have an existing routing,
it is possible we pick a CRTC that was previously routed to a connector
we have not enabled yet. If that happens, the latter connector cannot
preserve its routing.
Check that no other connector we might
> On 19 Apr 2018, at 15.09, Pekka Paalanen wrote:
>
> From: Pekka Paalanen
>
> Looking at the diff statistics of the changes authored by me and landed
> since 4.0.0 release points out these files as having major changes.
> Update the copyright holders accordingly.
>
> I have kept the redunda
From: Pekka Paalanen
To support shared-CRTC clone mode, the chosen CRTC needs to support
driving all the attached connectors. Replace the old algorithm with a
new one that takes into account all associated connectors.
Ideally it should use possible_clones mask to check which encoders (and
theref
From: Pekka Paalanen
When a head is detached from an enabled output, that output needs to go
through a modeset (drmModeSetCrtc() / ATOMIC_ALLOW_MODESET) so that the
connector is actually removed from the CRTC.
This has not yet been a problem, because an output could only have one
head at a time,
From: Pekka Paalanen
Rename user_data to wet, because it is called wet everywhere else.
Drop the local variable ec, because that is available as wet.compositor.
This models a little better that wet_compositor owns weston_compositor,
and not the other way around.
Signed-off-by: Pekka Paalanen
From: Pekka Paalanen
Looking at the diff statistics of the changes authored by me and landed
since 4.0.0 release points out these files as having major changes.
Update the copyright holders accordingly.
I have kept the redundant "Copyright ©" form only to keep things
consistent, even when either
From: Pekka Paalanen
This makes it easier to just pass wet_compositor around and take the
weston_compositor from it.
It feels weird to go from weston_compositor to wet_compositor all the
time in internal functions. It's necessary in callbacks that cannot
carry wet_compositor, but otherwise it is
From: Pekka Paalanen
Allow cloning up to 4 connectors from the same CRTC. All the
implementation bits support more than one head per output already.
Four is just an arbitary number, small but unlikely to ever be the
limiting factor in cloning since hardware is usually very restricted.
Signed-of
From: Pekka Paalanen
Add a new output section key "same-as" for configuring clone mode. An
output marked "same-as" another output will be configured identically to
the other output.
The current implementation supports only CRTC sharing for clone mode.
Independent CRTC clone mode cannot be suppor
From: Pekka Paalanen
Hi all,
this is actually clone mode series v9 part 3.
Yes, part 2 was never posted separately, it was landed directly from v6
as it didn't need any changes. This here is what are still left of the
roughly 135 patches I have written and recorded as part of the clone
mode wor
On Thu, 19 Apr 2018 09:26:59 +
"Ucan, Emre (ADITG/ESB)" wrote:
> Hi Pekka,
>
> If we remove the view from scenegraph, application will be blocked.
> Because it is not getting any surface frame events. It is not OK to
> block unexpected applications. Especially if the application is
> sending
Hi Pekka,
If we remove the view from scenegraph, application will be blocked. Because it
is not getting any surface frame events.
It is not OK to block unexpected applications. Especially if the application is
sending output of a camera or digital TV, weston should always get latest
buffer from
On Wed, 18 Apr 2018 15:44:26 +0200
Emre Ucan wrote:
> 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 p
18 matches
Mail list logo
