=== LockeAnarchist- is now known as LockeAnarchist | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
duflu_ | Hmm, is CI really asleep now? I guess it will take some hours to be sure | 03:41 |
---|---|---|
=== duflu_ is now known as duflu | ||
rsalveti | racarr: still around? | 04:33 |
rsalveti | racarr: do you know who is the one responsible for sending the input events to qt and then shell? | 04:37 |
rsalveti | racarr: just trying to understand the big picture | 04:37 |
rsalveti | my problem is that I'm getting KEY_PLAYPAUSE from the input device (kernel level), but I'm not getting Qt::Key_MediaTogglePlayPause in Qt, but getting another event id instead | 04:38 |
rsalveti | same for KEY_MEDIA | 04:38 |
rsalveti | I'm checking that in the qml available for the shell | 04:39 |
rsalveti | I know mir is handling the input events, but don't yet know how that works with the rest of the stack | 04:39 |
rsalveti | if it's something like evdev -> mir -> qt -> shell or different than that | 04:39 |
RAOF | rsalveti: That's right; evdev -> mir -> Qt -> shell. | 04:42 |
rsalveti | RAOF: do you know if mir is doing any parsing or filtering of the evdev events before sending that to Qt? | 04:43 |
rsalveti | also, do we need any sort of platform specific backend in Qt to handle the input device messages from Mir? | 04:44 |
rsalveti | this is specifically to touch, not sure if that would be any different from the desktop use case | 04:44 |
duflu | rsalveti: AFAIK we have a lack of key translation, which is a missing feature :) | 04:46 |
RAOF | rsalveti: So, we do some input parsing before feeding to Qt; the bit that you'd be interested in is in qtmir - src/platforms/mirserver/qteventfeeder.{h,cpp} | 04:46 |
rsalveti | awesome | 04:47 |
RAOF | As you see, that implements a mir::input::InputDispatcher, which hooks into the Mir event feeding. | 04:48 |
rsalveti | right, and hooks into Qt | 04:50 |
rsalveti | perfect, thanks! | 04:50 |
racarr | rsalveti: RAOF: By the time unity8 receives it its already gone through USC | 05:01 |
racarr | so the events are fully processed, keys are XKB mapped, etc... | 05:01 |
racarr | also my buffer stream bug is hilariously comical | 05:01 |
racarr | was | 05:02 |
racarr | *swats* | 05:02 |
RAOF | Don't leave us hanging! | 05:05 |
RAOF | racarr: Oh, yeah. That bit too :) | 05:05 |
racarr | RAOF: Haha...its hard to explain. Ok so imagine you are trying to implement | 05:06 |
racarr | ms::BasicSurface::set_cursor_buffer_stream(... | 05:07 |
* RAOF imagines | 05:07 | |
racarr | so I had the idea, ok well, it will just install an adapter object | 05:07 |
racarr | which will register itself as an observer with the buffer stream | 05:07 |
racarr | and each time a buffer appears, create a cursor image from it and | 05:08 |
racarr | just call Surface::set_cursor_image | 05:08 |
RAOF | This seems sensible. | 05:08 |
racarr | yeah not totally insane, not the easiest to make efficient but quick | 05:08 |
racarr | so, this adapter object is a member of the surface | 05:09 |
racarr | ...so in set_cursor_image | 05:09 |
RAOF | ...you take a lock... | 05:09 |
racarr | no haha even sillier | 05:09 |
racarr | I reset the adapter object! | 05:09 |
racarr | because | 05:09 |
racarr | set_cursor_image was a request to switch to | 05:09 |
racarr | an image | 05:09 |
racarr | an uninstall | 05:09 |
racarr | the buffer stream observer | 05:09 |
RAOF | Oooh, yeah! | 05:10 |
racarr | (which you would need to happen if you really did change to a static image) | 05:10 |
racarr | and then the icing on the cake is I eronneously concluded it was client buffer swaps not properly completing | 05:10 |
racarr | by debugging the deprecated SessionMediator::advance_buffer function | 05:11 |
racarr | lol | 05:11 |
RAOF | Hah. Gold! | 05:11 |
racarr | classic comedy lol | 05:11 |
racarr | ok thats good though | 05:11 |
racarr | then tomorrow morning I can focus on cleaning it up and in the afternoon | 05:11 |
racarr | on client clean up | 05:12 |
racarr | omg I never ate dinner | 05:12 |
RAOF | Ooops! | 05:12 |
racarr | hmm | 05:15 |
racarr | the Qt::Key_MediaTogglePlayPause problem must just be | 05:15 |
racarr | the static table in qteventfeeder | 05:15 |
racarr | however for clients... | 05:15 |
racarr | there is the other table in qtubuntu | 05:15 |
racarr | but how does (Qtmir::)MirSurfaceItem::consume | 05:16 |
racarr | work | 05:16 |
racarr | e.g. do we translate xkb key code -> qt key code -> back to xkb | 05:16 |
racarr | or is it broken and clients can't receive things like media keys | 05:16 |
racarr | for most things it will work because xkb key sym corresponds | 05:16 |
racarr | with qt keycode | 05:16 |
racarr | corresponds with unicode code point | 05:16 |
racarr | but media keys, etc are the exception and thats what the table is for | 05:16 |
racarr | *looks* | 05:17 |
racarr | ah not cool, qt tracks the "native virtual key" | 05:18 |
racarr | no* cool | 05:18 |
racarr | and thats used to reconstruct | 05:18 |
racarr | the mir event | 05:18 |
racarr | rsalveti: It should work if you add it to the top of the table at qteventfeeder.cpp | 05:19 |
racarr | WHAT TO EAT | 05:19 |
duflu | racarr: While you are cursor tinkering... it's occurred to me that a cursor isn't just per-surface but also varies between tools. E.g. mouse vs stylus vs finger touchpoints. They could (should) have different appearance | 05:51 |
duflu | When playing with a stylus I thought it would be nice if the cursor on screen showed which tool actually produced the last event to move the cursor | 05:52 |
racarr | mm maybe | 05:53 |
racarr | I think shells should be able to implement that | 05:54 |
duflu | racarr: Yeah definitely shells/clients pick the images. But you have to tell them from the server what the tool is | 05:55 |
duflu | But before all that, we would need to teach Android input how to move the cursor with tools other than the mouse | 05:56 |
duflu | Because it doesn't want to | 05:56 |
racarr | yeah, after we transition out old MirKeyEvent and MirMotionEvent | 05:59 |
racarr | im looking forward to starting to unwind this by differentiating | 05:59 |
racarr | MirTouchInputEvent and MirPointerInputEvent | 05:59 |
duflu | racarr: Which is a hovering stylus? :) | 05:59 |
racarr | and all the various combinations of synthesis required to support, synaptics, pointer emulation, wacom<->pointer, etc. | 05:59 |
racarr | duflu: Well, in this case if the stylus was configured for pointer emulation | 06:00 |
racarr | you would first receive the "raw" MirTouchInputEvent | 06:00 |
racarr | and it would have a non null | 06:00 |
racarr | "synthesized_to" member | 06:00 |
racarr | which is the ID, of an event which you can expect immediately | 06:00 |
racarr | synthesized from the event | 06:00 |
racarr | and the client can choose to interpret it | 06:01 |
racarr | as a touch | 06:01 |
duflu | Hmm, I've got another semi-broken laptop with stylus. I think it turns on now... so will try that | 06:01 |
racarr | or interpret the cursor motion in the synthetic pointer event | 06:01 |
racarr | I mean it definitely | 06:01 |
racarr | doesnt work at the moment haha | 06:01 |
duflu | racarr: I like how it works now (stylus is like a finger). Just want a cursor shown during hover | 06:01 |
RAOF | Hm. | 06:35 |
RAOF | I don't think you want per-tool cursors. | 06:35 |
RAOF | But mainly because only the mouse - virtual or otherwise - has a cursor. | 06:35 |
RAOF | Touchpoints obviously don't get cursors; the stylus likewise. | 06:35 |
RAOF | (Unless it's manipulating the virtual mouse cursor, but in that case see virtual mouse cursor) | 06:36 |
duflu | RAOF: I can see a cursor for the stylus in X. But would prefer it looked different to the mouse | 06:52 |
RAOF | How would that work? | 06:53 |
RAOF | The cursor would change depending on what input device you touched? | 06:53 |
duflu | RAOF: Change the cursor to match whatever tool caused it to move last | 06:53 |
RAOF | That's possible, I guess, but why would you ever want to do that? | 06:54 |
RAOF | It always does the same thing. | 06:54 |
duflu | RAOF: It's a subtle bit a feedback that makes the user more comfortable that the system understands what they're doing | 06:55 |
duflu | An arrow for the stylus looks kludgy | 06:56 |
RAOF | Maybe, I guess? | 06:56 |
duflu | And may be visibly annoying too (too big) | 06:56 |
duflu | Man, I'm digging myself in. This branch went from just implementing fullscreen to doing half the WM spec | 06:57 |
duflu | Still in under 1000 lines :) | 06:57 |
RAOF | If you're using the stylus for anything stylus-y then you won't have the arrow, anyway? | 06:58 |
RAOF | It might be useful; I suspect that it'll actually appear weird. | 06:58 |
duflu | RAOF: If you're using the stylus primarily then you don't want to switch to mouse to click a button. So you have to see where you're aiming | 06:59 |
RAOF | Right, but why would you want the cursor to be smaller when you're using the stylus? | 07:00 |
duflu | RAOF: I guess I'm imagining that a paint app forgets to change its cursor | 07:00 |
RAOF | :) | 07:01 |
=== chihchun is now known as chihchun_afk | ||
mlankhorst | does eglSwapBuffers block? | 11:40 |
mlankhorst | or what call should I use to check when a new mir surface is available for rendering | 11:40 |
=== alan_g is now known as alan_g|lunch | ||
mlankhorst | oh seems to block then.. | 14:18 |
=== dandrader_ is now known as dandrader|afk | ||
=== alan_g|lunch is now known as alan_g | ||
=== dandrader|afk is now known as dandrader | ||
=== chihchun_afk is now known as chihchun | ||
=== Saviq_ is now known as Saviq | ||
=== chihchun is now known as chihchun_afk | ||
=== dandrader is now known as dandrader|lunch | ||
=== dandrader|lunch is now known as dandrader | ||
=== alan_g_ is now known as alan_g|EOD | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!