Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch to using libinput exclusively (x86 / Generic only) #200

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@lrusak
Copy link
Member

commented Apr 21, 2016

Let's give this a go again.

positive reports so far from @MilhouseVH

@@ -49,11 +49,7 @@ fi
get_graphicdrivers

# Drivers
if [ -n "$LIBINPUT" ]; then
PKG_DEPENDS_TARGET="$PKG_DEPENDS_TARGET xf86-input-libinput"

This comment has been minimized.

Copy link
@ghost

ghost Apr 23, 2016

Indentation correct?

@lrusak

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2016

@MilhouseVH any feedback here?

@lrusak

This comment has been minimized.

Copy link
Member Author

commented May 2, 2016

Maybe @whot would be so kind to help us out with out remote issues.

Maybe it's just a matter of shipping both xf86-input-evdev and xf86-input-libinput together? I think libinput rules would override the former but I'm not 100% sure.

@whot

This comment has been minimized.

Copy link

commented May 3, 2016

how do you guys use the remote? can you file a bug against libinput on bugs.freedesktop.org and attach the evemu-describe output from one of these devices?

libinput does not really support remotes yet, it probably handles (some of) them as keyboards but that's not the long-term plan. So in the meantime you should keep using evdev against remotes, but that would require custom xorg.conf snippets since libinput by default overrides evdev for keyboards (and remotes largely look like keyboards).

@MilhouseVH

This comment has been minimized.

Copy link
Contributor

commented May 4, 2016

There have been several reports in the test thread of auto-repeat not working since the switch to libinput. I'm going to drop this PR from the next test build - let's see if all the remote issues clear up. Assuming this PR is responsible for these issues, this PR should be put on hold or closed until there's a solution.

@lrusak

This comment has been minimized.

Copy link
Member Author

commented May 4, 2016

@whot The remotes are typically used through lirc or eventlircd. I'll see what I can do about getting a bug report going, however, I don't have any of these remotes so we'll have to get a user to volunteer.

@MilhouseVH

This comment has been minimized.

Copy link
Contributor

commented May 5, 2016

Dropping this PR has restored the "missing buttons" but hasn't fixed the auto-repeat issue, could this be due to the kernel change (the switch to libinput and 4.6-rc4 occurred at the same time, build #423). I'm going to do a clean build for tonight just to be absolutely sure...

@whot

This comment has been minimized.

Copy link

commented May 5, 2016

fwiw, libinput does nothing with auto-repeat, like evdev it swallows kernel repeat events and relies on the higher levels to do repeating.

@lrusak lrusak force-pushed the LibreELEC:master branch from 2d52a20 to c6c222d Jun 19, 2016

@chewitt

This comment has been minimized.

Copy link
Member

commented Feb 5, 2017

@lrusak is this still relevant?

@lrusak

This comment has been minimized.

Copy link
Member Author

commented Feb 5, 2017

I use libinput in all my generic builds.

It would be nice to switch but we need to find a good way to test remotes so that they still work properly.

@chewitt

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

@lrusak sending a bi-annual ping on this. It's not part of the OS that I understand :)

@lrusak

This comment has been minimized.

Copy link
Member Author

commented Jun 27, 2017

It would be worth a test again. We need to nail down which remotes break when libinput is used.

@chewitt

This comment has been minimized.

Copy link
Member

commented Sep 13, 2017

@lrusak given the general mid-term direction towards exorcising Xorg can this be closed?

@libreelec-jenkins

This comment has been minimized.

Copy link

commented Jan 10, 2018

Jenkins Test

@libreelec-jenkins

This comment has been minimized.

Copy link

commented Jan 10, 2018

Jenkins test

@libreelec-jenkins

This comment has been minimized.

Copy link

commented Jan 10, 2018

test

thoradia pushed a commit to thoradia/LibreELEC.tv that referenced this pull request May 22, 2019

Merge pull request LibreELEC#200 from Portisch/Revert_ScreenshotAML
Revert "Kodi: update ScreenshotAML to use the CAP_FLAG_AT_END method"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.