Skip to content

Initial linux touch implementation#1706

Closed
ap4ss3rby wants to merge 14 commits intoLizardByte:nightlyfrom
ap4ss3rby:nightly
Closed

Initial linux touch implementation#1706
ap4ss3rby wants to merge 14 commits intoLizardByte:nightlyfrom
ap4ss3rby:nightly

Conversation

@ap4ss3rby
Copy link

@ap4ss3rby ap4ss3rby commented Oct 5, 2023

I may or may not have missed a lot of details, but I hope someone else can fix my semi-working MT code to properly work.

Needs a properly patched Moonlight client for android testing with this patch reverted

Description

Currently, the code in this PR does the following:

  • Break Windows and macOS builds because I couldn't be bothered to fix their touch() functions for the touch device parameter
  • Report that we infact have touch capability on linux hosts
  • Probably break absolute mouse mode even more
  • Report native touch events using uinput. Making stuff like streaming waydroid to a phone for playing Android games at better quality than just playing directly on the phone possible
  • Not do multitouch because uinput is stupid and doesn't like how I'm feeding it multitouch data

Screenshot

Issues Fixed or Closed

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Dependency update (updates to dependencies)
  • Documentation update (changes to documentation)
  • Repository update (changes to repository files, e.g. .github/...)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

  • I want maintainers to keep my branch updated

I may or may not have missed a lot of details, but I hope someone else can fix my semi-working MT code to properly work.

Needs a properly patched Moonlight client for android testing
@CLAassistant
Copy link

CLAassistant commented Oct 5, 2023

CLA assistant check
All committers have signed the CLA.

@ReenigneArcher ReenigneArcher marked this pull request as draft October 5, 2023 22:19
@ap4ss3rby ap4ss3rby changed the title Initial linux touch implementation WIP: Initial linux touch implementation Oct 5, 2023
@ap4ss3rby ap4ss3rby changed the title WIP: Initial linux touch implementation Initial linux touch implementation Oct 7, 2023
@ap4ss3rby ap4ss3rby marked this pull request as ready for review October 7, 2023 19:52
@ap4ss3rby
Copy link
Author

ap4ss3rby commented Oct 7, 2023

After fixing a bunch of mistakes with my understanding of uinput and implementing what I learned I was able to get at least 8 points recognized (couldn't test more because I ran out of space on my phone haha), and it should recognize up to 10

@ReenigneArcher ReenigneArcher requested a review from cgutman October 7, 2023 19:56
get_capabilities() {
return 0;
platform_caps::caps_t caps = 0;
caps |= platform_caps::pen_touch;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You also have to implement pen() or Moonlight will start sending native pen events that just get ignored.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will implement but will require external testing since I don't have anything capable of doing pen events.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can test with my devices

libevdev_enable_event_code(dev.get(), EV_ABS, ABS_MT_SLOT, &mtslot);
libevdev_enable_event_code(dev.get(), EV_ABS, ABS_MT_TRACKING_ID, &trkid);
libevdev_enable_event_code(dev.get(), EV_ABS, ABS_MT_POSITION_X, &absx);
libevdev_enable_event_code(dev.get(), EV_ABS, ABS_MT_POSITION_Y, &absy);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use a separate uinput device for pen/touch input, create it on demand (on the first pen/touch event), and store it in the client_input_t. You can use the Windows implementation as reference.

libevdev_uinput_write_event(touchscreen, EV_ABS, ABS_MT_TRACKING_ID, id);
libevdev_uinput_write_event(touchscreen, EV_ABS, ABS_MT_POSITION_X, scaled_x);
libevdev_uinput_write_event(touchscreen, EV_ABS, ABS_MT_POSITION_Y, scaled_y);
libevdev_uinput_write_event(touchscreen, EV_SYN, SYN_REPORT, 0);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also implement ABS_MT_TOOL_TYPE, ABS_MT_PRESSURE, ABS_MT_ORIENTATION, ABS_MT_TOUCH_MAJOR, and ABS_MT_TOUCH_MINOR.

ABS_MT_TOOL_TYPE should always be MT_TOOL_FINGER in this codepath.

ABS_MT_PRESSURE, ABS_MT_TOUCH_MAJOR, and ABS_MT_TOUCH_MINOR should be pretty simple. Just scale the 0-1 float to some arbitrary integer range (touch major and minor have to be same range as X/Y) and be sure to handle the "unknown" cases. See the API docs here: https://github.com/moonlight-stream/moonlight-common-c/blob/d457fbb48714d4ce79de2594180dfd73bc5f070c/src/Limelight.h#L594-L629

Finally, ABS_MT_ORIENTATION might need some extra conversion logic to get to the evdev format.

You can reuse all this logic for the pen implementation too, in addition to adding ABS_MT_DISTANCE, BTN_STYLUS/BTN_STYLUS2, and ABS_MT_TOOL_TYPE. I think ABS_TILT_X and ABS_TILT_Y is also valid for stylus devices.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we're going towards a full fat implementation instead of a basic one. Got it. Keep in mind I dropped some tablet related events since they seemed to cause problems with KDE Plasma and the easiest solution was to just drop tablet related events.

If I can get around them I'll implement them into one device type. Otherwise I'll split touchscreen and tablet types if we're gonna create a new global context whenever we recieve a touch/tablet packet just to save myself a bit of headache

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I can get around them I'll implement them into one device type. Otherwise I'll split touchscreen and tablet types if we're gonna create a new global context whenever we recieve a touch/tablet packet just to save myself a bit of headache

I assume you mean splitting into separate uinput devices. That's totally fine if it's more convenient to expose separate pen and multitouch touchscreen devices.

@WesleyVanNeck
Copy link

@ap4ss3rby do you know why on wayland i only get about 2 touch inputs

@WesleyVanNeck
Copy link

on kde it works fine do the mouse cursor shows up

@ReenigneArcher
Copy link
Member

@ap4ss3rby are you able to implement the remaining changes requested by @cgutman?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants