[05:57] <duflu> RAOF: Fun fact: while our drivers don't link in a well-behaved fashion ${shlibs:Depends} finds no dependencies
[05:57] <duflu> Obviously
[05:57] <duflu> But there really should be some
[06:01] <duflu> Although they're utterly unusable without the prerequisite libmirplatform so it's probably a clean and harmless dependency omission
[06:06] <RAOF> Well, as it currently stands they don't _really_ have a dependency on libmirplatform.
[06:06] <RAOF> They get those symbols from the libmirserver they're loaded into :)
[06:35] <duflu> RAOF: Yeah symbols needed at runtime. But there's no reason to accurately detail those dependencies in the package details
[06:35] <duflu> If you don't have the deps you can't load the drivers
[06:35] <RAOF> Right.
[06:36] <RAOF> (At some glorious future point you'll be able to load a driver linked against libmirplatform.so.N into a libmirserver linked against libmirserver.so.M and have everything work, but that's not now)
[07:00] <duflu> RAOF: I'm not totally comfortable I know what the "platform" is yet. Would be nice to find the time for me to write a new driver as a learning exercise
[07:04] <RAOF> I started an X11 one on Friday.
[07:04] <duflu> Woot
[07:05] <duflu> RAOF: Is a new mesa for utopic coming at all?
[07:05] <RAOF> There's a surprising amount of Mir scattered through there.
[07:05] <RAOF> duflu: I believe that mlankhorst is prepping a new Mesa now.
[07:05] <duflu> All good news
[07:05]  * duflu should log off early today in case that changes :)
[07:06] <RAOF> Heh.
[07:06] <RAOF> Of course, the X11 platform is only for output, and won't work for input...
[07:06] <RAOF> That requires a reworking of “Platform” to fix.
[07:07] <RAOF> But would be nice; then we'd have 4 1st class platforms - Mesa+evdev, Android+evdev, Mir, X11.
[07:08] <duflu> RAOF: Not sure Mir is 1st class or higher than that even... since it's not an explicit driver implementation
[07:09] <RAOF> Oh, but it is.
[07:09] <RAOF> It's just that we don't treat it as such.
[07:09] <duflu> 0.8th class (for royalty only)
[07:09] <RAOF> (And, also, because we don't have any sort of input platform the Mir platform needs to be tightly bound)
[07:10] <RAOF> But with not _too_ much work that binding can be cut.
[07:10] <duflu> Yay, options
[19:19] <bschaefer> racarr, hey, would you happen to know whos in-charge of setting the tool type for motion events? As im pretty sure we just copy it from the android event ... but for some reason I keep getting a 0 tool type (which is AMOTION_EVENT_TOOL_TYPE_UNKNOWN)
[19:19]  * bschaefer re-calls hitting that problem a few months ago...
[19:24] <racarr> bschaefer: I don't actually know what happens to that no...
[19:25] <racarr> bschaefer: We dont even have mir defines, so I guess there is some work to do, if nothing else it needs to be under test
[19:25] <racarr> and it sounds like this test would fail lol...
[19:25] <racarr> can you file a bug?
[19:25] <racarr> I'm getting ready to go to lunch as soon as the rain clears up
[19:25] <racarr> and dont want to forget
[19:25] <bschaefer> racarr, sure, i assume we never want a tool type to be UNKNOWN
[19:25] <bschaefer> racarr, thanks!
[19:30] <racarr> bschaefer: I guess sometimes its inevitable probably but preferably not
[19:30] <bschaefer> yeah
[19:32] <bschaefer> racarr, i should test it on the desktop to see if the MOUSE tool type is getting set correctly...i wonder if arm is doing something strange under the hood there...
[19:34] <bschaefer> racarr, it could be worded poorly, but edit it how you think it should sound: https://bugs.launchpad.net/mir/+bug/1371282
[19:34] <bschaefer> :)
[19:34] <racarr> bschaefer: Yay. thank you...will parse after lunch
[19:34] <bschaefer> thanks! enjoy
[19:34]  * bschaefer should eat at some point