[03:41] <duflu_> Hmm, is CI really asleep now? I guess it will take some hours to be sure
[04:33] <rsalveti> racarr: still around?
[04:37] <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:38] <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:39] <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:42] <RAOF> rsalveti: That's right; evdev -> mir -> Qt -> shell.
[04:43] <rsalveti> RAOF: do you know if mir is doing any parsing or filtering of the evdev events before sending that to Qt?
[04:44] <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:46] <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:47] <rsalveti> awesome
[04:48] <RAOF> As you see, that implements a mir::input::InputDispatcher, which hooks into the Mir event feeding.
[04:50] <rsalveti> right, and hooks into Qt
[04:50] <rsalveti> perfect, thanks!
[05:01] <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:02] <racarr> was
[05:02] <racarr> *swats*
[05:05] <RAOF> Don't leave us hanging!
[05:05] <RAOF> racarr: Oh, yeah. That bit too :)
[05:06] <racarr> RAOF: Haha...its hard to explain. Ok so imagine you are trying to implement
[05:07] <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:08] <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:09] <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:10] <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:11] <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:12] <racarr> on client clean up
[05:12] <racarr> omg I never ate dinner
[05:12] <RAOF> Ooops!
[05:15] <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:16] <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:17] <racarr> *looks*
[05:18] <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:19] <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:51] <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:52] <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:53] <racarr> mm maybe
[05:54] <racarr> I think shells should be able to implement that
[05:55] <duflu> racarr: Yeah definitely shells/clients pick the images. But you have to tell them from the server what the tool is
[05:56] <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:59] <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.
[06:00] <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:01] <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:35] <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:36] <RAOF> (Unless it's manipulating the virtual mouse cursor, but in that case see virtual mouse cursor)
[06:52] <duflu> RAOF: I can see a cursor for the stylus in X. But would prefer it looked different to the mouse
[06:53] <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:54] <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:55] <duflu> RAOF: It's a subtle bit a feedback that makes the user more comfortable that the system understands what they're doing
[06:56] <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:57] <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:58] <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:59] <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
[07:00] <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:01] <RAOF> :)
[11:40] <mlankhorst> does eglSwapBuffers block?
[11:40] <mlankhorst> or what call should I use to check when a new mir surface is available for rendering
[14:18] <mlankhorst> oh seems to block then..