<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 11:58 AM, Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
One of the things we talked about during Akademy was better support for<br>
convertible hardware. I've played around a bit with my Thinkpad X1 Yoga<br>
and screen rotation. I can of course rotate the screen "manually"<br>
through XRandR (Wayland is another story on that altogether), but that<br>
will screw up the touchscreen. Doing some research, I found out that:<br>
<br>
- touchscreen and display are completely separate things, the system<br>
  doesn't know they're sitting on top of each other<br>
- They need to be rotated separately<br>
- rotation in X goes through XInput2, on Wayland, I don't know<br></blockquote><div><br></div><div>on wayland<br></div><div>touch is libinput->kwin->app  (protocol is wl_touch)<br></div><div><br></div><div>But AFAIK actual screen rotation itself needs to be added to kwin wayland, before we can be looking at fixing touch events.</div><div><br></div><div>I'm not 100% sure the input needs transforming when rotated. If you look at QtWaylandWindow when the screen rotates, the surface rotates too, so if co-ordinates are surface local we shouldn't be changing it?   <br>It's quite confusing.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm working on some code that does the rotation from KScreen right now.<br>
My idea is to add this to KScreen's API and allow the KScreen user to<br>
also rotate the display.<br>
<br>
On X, this happens async, and this bears the risk that input ends up on<br>
different coordinates during switching (display has already rotated,<br>
touchscreen still in process, or some race condition like that -- I<br>
don't think we can really prevent that), on Wayland, we should be able<br>
to prevent that from happening as we hopefully can make input rotation<br>
atomic along with the rotation itself, the protocol and API of screen<br>
management in Wayland allow that.<br>
<br>
We probably will need to guess which display has a touchscreen<br>
attached, but for some cases, I think we can make some pretty<br>
reasonable guesses<br>
- one display, one touchscreen seems like a the most common case, and<br>
is clear<br>
- one touchscreen and multiple displays: touchscreen may be on the<br>
internal display<br>
The mapping heuristic is kept internally, and we can work on that<br>
later, once we got the basics in place.<br>
<br>
Architecture / API design: My idea right now is to add a new relatively<br>
simple type class to the KScreen API, TouchScreen, that can be received<br>
from an Output, something like<br>
<br>
output->setRotation(Output::<wbr>Left);<br>
TouchscreenList *touchscreens = output->touchscreens();<br>
for (auto touchscreen : touchscreens) {<br>
        <a href="http://touchscreens.at" rel="noreferrer" target="_blank">touchscreens.at</a>(0)-><wbr>setRotation(Output::Left);<br>
}<br>
// ... then setting the new config as usual through SetConfigOperation()<br></blockquote><div><br></div><div>I don't undertand what this help with?<br><br></div><div>That will store a value, but you haven't said who's going to do anything with it, which is the important part.<br><br>If we're going to set it to be the same as the screen we may as well just have the code that handles input to read the screen rotation.<br></div></div></div></div>