[PATCH libinput 7/8] tablet: fake a BTN_TOOL_PEN on the first event if needed

Some (?) Aiptek tablets have BTN_TOOL_PEN but aren't inclined to actually send this on proximity in. This means we don't have a tool assigned and ignore the events. This patch piggy-backs on the already-existing proximity-out quirks. On the first EV_SYN and if the tool is still NONE (i.e. no

[PATCH libinput 4/8] tablet: release the tablet state on device delete

When the device gets deleted in a non-neutral state, we need to release all buttons, lift the tip up and send a proximity out event. https://bugs.freedesktop.org/show_bug.cgi?id=104940 Signed-off-by: Peter Hutterer --- src/evdev-tablet.c | 6 test/test-tablet.c

[PATCH libinput 8/8] Add a test device for aiptek tablets

This tablet advertises tilt but doesn't actually have it. Let's rule out tilt for all aiptek devices until someone complains. Recording from: https://bugzilla.redhat.com/show_bug.cgi?id=1535755 Related to: https://bugs.freedesktop.org/show_bug.cgi?id=104911 Signed-off-by: Peter Hutterer

[PATCH libinput 3/8] tablet: don't set rotation on a tool if we don't have ABS_Z

Rotation on a tool can either ABS_Z or in the case of the mouse/lens tools a combination of ABS_TILT_X/Y. The code assumes that if the rotation on a stylus (not mouse/lense) changes, we need to fetch it from ABS_Z. This happens on the very first event from the tablet, proximity in invalidates all

[PATCH libinput 5/8] tablet: skip tablet_flush() if our current tool type is none

If a tablet never sends a BTN_TOOL_foo, we never update the tool and we remain on the 'none' tool. Somewhat related to: https://bugzilla.redhat.com/show_bug.cgi?id=1535755 https://bugs.freedesktop.org/show_bug.cgi?id=104911 Signed-off-by: Peter Hutterer ---

[PATCH libinput 1/8] test: make the mouse tool a litest feature bit

Aiptek tablets have the BTN_TOOL_MOUSE|LENS bits but don't actually have a mouse, at least not in libinput (see future patches). Turns out we only have one device that really has the tool anyway, so not running the tests for the others seems sensible. Signed-off-by: Peter Hutterer

[PATCH libinput 0/8] Quirks and fixes for non-Wacom tablets (Aiptek)

The one thing we can rely on from non-wacom tablets is that they're less inclined to follow the established evdev behaviours. The Aiptek tablet in this case doesn't send BTN_TOOL_PEN or any other tools, despite having the bits. It also doesn't care about tilt, because clearly, just pretending tilt

[PATCH libinput 6/8] tablet: disable BTN_TOOL_MOUSE/LENS for non-Wacom tablets

Mouse and lens cursor tools are rare and the rotation calculation is quirky to say the least. I don't have access to a non-Wacom mouse tool, so until this changes, just disable those tools and wait for someone to shout. This is a much easier fix than trying to figure out the correct generic

[PATCH weston 3/4] shared: Update all users of DATADIR

Replace every use of DATADIR to create a filename with a call to the new function that allows overriding DATADIR with an env var at runtime. No attention is paid to asprintf failure. This restores make distcheck to a passing state after commit 6b58ea began checking cairo surfaces for validity

[PATCH weston 1/4] shared: Add a function to prefix filenames with datadir

Currently we look for png files in their install directory, and we manufacture filenames with string pasting at compile time. This new function will allow overriding the compile time setting with the env var WESTON_DATA_DIR so we can do neat tricks like allow our test suite to pass when we

[PATCH weston 0/4] Fix distcheck by overriding file directories

So apparently for a Very Long Time make distcheck has passed with log errors indicating missing files since many icons have been searched for in their system wide install directory, but the check phase of the build comes before the install phase of the build. That wasn't a big deal until fairly

[PATCH weston 2/4] tests: Set WESTON_DATA_DIR for tests

Set the env var to override the system data directory so we can run tests with uninstalled icons. We don't yet use the code that checks this env var, so make distcheck will still fail. Signed-off-by: Derek Foreman --- tests/weston-tests-env | 4 1 file changed, 4

Re: [PATCH v15 03/34] compositor-drm: Move repaint state application to flush

Hi, On 6 February 2018 at 12:25, Pekka Paalanen wrote: > I found some little details to fix, but other than those, it looks good. Thanks! For the record, I've fixed all these before pushing. > One thing I noticed in the legacy KMS path is that we don't tend to > program

Re: [PATCH v15 09/34] compositor-drm: Atomic modesetting support

On 6 February 2018 at 13:51, Pekka Paalanen wrote: > On Mon, 5 Feb 2018 18:44:18 + > Daniel Stone wrote: >> Add support for using the atomic-modesetting API to apply output state. >> Unlike previous series, this commit does not unflip

Re: [PATCH v15 06/34] compositor-drm: Don't restore original CRTC mode

On Tue, 6 Feb 2018 13:53:21 + Daniel Stone wrote: > Hi Pekka, > > On 6 February 2018 at 13:30, Pekka Paalanen wrote: > > On Mon, 5 Feb 2018 18:44:15 + > > Daniel Stone wrote: > >> @@ -4296,7 +4290,8 @@

Re: [PATCH v15 06/34] compositor-drm: Don't restore original CRTC mode

Hi Pekka, On 6 February 2018 at 13:30, Pekka Paalanen wrote: > On Mon, 5 Feb 2018 18:44:15 + > Daniel Stone wrote: >> @@ -4296,7 +4290,8 @@ drm_output_destroy(struct weston_output *base) >>*/ >> if

Re: [PATCH v15 09/34] compositor-drm: Atomic modesetting support

On Mon, 5 Feb 2018 18:44:18 + Daniel Stone wrote: > Add support for using the atomic-modesetting API to apply output state. > Unlike previous series, this commit does not unflip sprites_are_broken, > until further work has been done with assign_planes to make it

Re: [PATCH] shm: provide actual error on mmap failed

On Mon, Feb 05, 2018 at 03:39:43PM +0100, Olivier Fourdan wrote: > When an mmap() fails, a WL_SHM_ERROR_INVALID_FD is raised and the client > is killed. > > However, there is no indication of the actual system error that caused > mmap() to fail, which makes such error harder to investigate. > >

Re: [PATCH v15 06/34] compositor-drm: Don't restore original CRTC mode

On Mon, 5 Feb 2018 18:44:15 + Daniel Stone wrote: > When leaving Weston, don't attempt to restore the previous CRTC > settings. The framebuffer may well have disappeared, and in every > likelihood, whoever gets the KMS device afterwards will be repainting > anyway. >

Re: [PATCH v15 05/34] compositor-drm: Consistent failure paths for output creation

On Mon, 5 Feb 2018 18:44:14 + Daniel Stone wrote: > Rather than a smattering of error handlers, use consistent jump labels > for error paths in create_output_for_connector(). > > Signed-off-by: Daniel Stone > Reported-by: Pekka Paalanen

Re: [PATCH v15 03/34] compositor-drm: Move repaint state application to flush

On Mon, 5 Feb 2018 18:44:12 + Daniel Stone wrote: > Split repaint into two stages, as implied by the grouped-repaint > interface: drm_output_repaint generates the repaint state only, and > drm_repaint_flush applies it. > > This also moves DPMS into output state.

Re: [PATCH v15 02/34] compositor-drm: Disable unused CRTCs/connectors

On Mon, 5 Feb 2018 18:44:11 + Daniel Stone wrote: > If we have an unused CRTC or connector, explicitly disable it during the > end of the repaint cycle, or when we get VT-switched back in. > > This commit moves state_invalid from an output property to a backend >

[ANNOUNCE] libinput 1.9.902

The second RC for libinput 1.10 is now available. Most of the patches went towards the test suite, specifically to avoid having the host suspend or shut down during a test suite run. Amazing what difference that makes! The logging system was improved that our messages are all printed as one line

Re: [PATCH v15 01/34] compositor-drm: Track unused connectors and CRTCs

On Mon, 5 Feb 2018 18:44:10 + Daniel Stone wrote: > Rather than a more piecemeal approach at backend creation, explicitly > track connectors and CRTCs we do not intend to use, so we can ensure > they are disabled where appropriate. > > When we have an updated list of

Re: [PATCH v15 00/34] Atomic modesetting

On Mon, 5 Feb 2018 18:44:09 + Daniel Stone wrote: > Hi, > Thanks a lot to Pekka and Philipp in particular for their really > thorough review; things seem to be looking quite positive now! > > I am _mostly_ sending this for the part up until the patch which > actually

Re: [PATCH v15 34/34] drm debug

On Tue, 6 Feb 2018 07:29:41 + "Ucan, Emre (ADITG/ESB)" wrote: > Hi, > > Did you send this patch erroneously ? Weston will print out lots of > logs after this patch. It's mentioned in the cover letter. > > -Original Message- > > From: wayland-devel