[02:51] <duflu> robert_ancell: Hey I'm still catching up after vacationing. What's the state of GTK-Mir?
[02:51] <robert_ancell> duflu, hey
[02:52] <robert_ancell> duflu, it's in the archive now. The patch is pretty basic, the main feature we're blocked on from Mir is support for multiple windows
[02:52] <robert_ancell> The main blocker in Unity is allowing GTK+ applications to be launched without editing the .desktop files (probably using a hard-coded whitelist for now)
[02:53] <duflu> robert_ancell: Yeah that's a Unity8 thing. I'm just wondering about the packages. So standard utopic gtk3 supports Mir?
[02:53] <robert_ancell> yes
[02:53] <duflu> Awesome
[02:53] <duflu> Very nice
[02:53] <duflu> I shall have to play
[02:53] <robert_ancell> We'll just update the debian patch from GNOME Git when we change it there
[02:53] <duflu> robert_ancell: Got a list of "pure" apps that work without recompiling?
[02:54] <robert_ancell> duflu, I've been playing with gedit, gnome-calculator, simple-scan as test cases
[02:54] <robert_ancell> Just set X-Ubuntu-Touch=true in the .desktop files to show then in Unity
[02:54] <duflu> robert_ancell: Straight from utopic archive?
[02:54] <robert_ancell> just with the above change
[02:54] <duflu> robert_ancell: How about demo shell?
[02:55] <robert_ancell> They run in there fine
[02:55] <duflu> Handy
[02:55] <robert_ancell> You just need to set MIR_SOCKET and permissions appropriate
[02:55] <duflu> I didn't see any news about this milestone. But I also didn't read news during June
[02:55] <robert_ancell> fine = as well as we currently have support for
[02:55] <robert_ancell> in the public?
[02:56] <duflu> Yeah
[02:56] <robert_ancell> http://www.omgubuntu.co.uk/2014/06/ubuntu-devs-demo-gtk-apps-running-mir-unity-8
[02:57] <robert_ancell> I haven't mentioned it's all in the archive now because it's not much use until Unity 8 shows the apps by default
[03:07] <duflu> robert_ancell: What's underneath? Is it cairo on GL? cairo on software?
[03:07] <robert_ancell> duflu, cairo on software
[03:07] <duflu> robert_ancell: Oh so we have a cairo port
[03:07] <duflu> ?
[03:07] <robert_ancell> duflu, no, cairo just renders to the surface memory
[03:08] <robert_ancell> it has no idea about mir
[03:08] <duflu> robert_ancell: Ah, right. Cairo just uses pointers to memory
[03:08] <robert_ancell> We can't have cairo on GL because that requires libGL to be linked to it and nvidia libGL would use crazy amounts of memory
[03:08] <robert_ancell> cairo on GL also slower in some cases still
[03:09] <duflu> robert_ancell: Well Cairo on GL is completely unnecessary for use cases where your surfaces are pre-generated
[03:09] <duflu> (don't change much)
[03:09] <robert_ancell> yeah
[03:10] <duflu> robert_ancell: Did you encounter many gnome apps with X linkage?
[03:11] <robert_ancell> not very many, and they've mostly been fixed because Wayland has the same issues
[03:11] <robert_ancell> We had a couple of GTK+ plugins for Ubuntu that were assuming X, but we just disable them if not under X and they work fine
[03:13] <duflu> Heh. Nothing like supporting multiple platforms to improve code quality
[03:16] <robert_ancell> oh, you also have to unset DISPLAY because GDK tries the X11 backend before the Mir one
[03:20] <duflu> robert_ancell: OK. I'll try to get through all the un-fun tasks today and then try it
[03:47] <duflu> How exactly am I involved in 2/3rds of all code reviews already?
[03:47] <duflu> I need to close my eyes more
[06:28] <RAOF> duflu: What would you like as an overview for RPC work?
[06:29] <duflu> RAOF: I guess just more description of what the goal/advantages are
[06:29] <duflu> It's shinier and you'll lose 10kg
[06:29] <duflu> (tm)
[06:29] <duflu> Buy now
[06:35] <RAOF> duflu: Description updated for you :)
[06:36] <duflu> RAOF: Mostly curious. I have no immediate plans to do an in-depth review or block it
[06:36] <RAOF> Ah.
[06:40] <RAOF> Basically, it makes us more awesome.
[06:48] <RAOF> Boo! I was using test_file_descriptors!
[06:49] <RAOF> Although all those reasons for its removal are perfectly true. The split-rpc-transport branch has some better tests for fd passing, too.
[06:50] <duflu> RAOF: "removes our current serialisation of reads/writes" ... we don't lose ordering guarantees of messages like events do we?
[06:50] <RAOF> No. It means “writes are no longer serialised with reads”
[06:51] <duflu> RAOF: Cool. And "expose manual event dispatch" ... what's that?
[06:51] <RAOF> Handing a file descriptor out to GTK that, when it becomes readable, GTK can call mir_connection_dispatch() and have all the processing happen there.
[06:52] <RAOF> ie: threading only when you want it..
[06:54] <duflu> Sounds nice
[06:57] <duflu> RAOF: I was about to try benchmarking the protocol change and see if it's different... but can't build
[06:57] <duflu> Maybe later
[06:57] <RAOF> duflu: Indeed. See above, “I was using test_file_descriptors!” :)
[06:58] <duflu> I lacked the context back then
[06:58] <duflu> Time to fix dednick's tests then
[06:59] <RAOF> Eh, I can just use a different message.
[07:06] <RAOF> duflu: There we go, now builds again.
[08:13] <RAOF> BAH!
[08:13] <RAOF> Next time we're sprinting, can we please have a session on profiling? :)
[08:13] <RAOF> Anyway, EOD here.
[10:35] <anpok_> mzanetti: http://paste.ubuntu.com/7764887/ please try
[10:35] <mzanetti> anpok_: hey cool, thanks. will try.
[10:35] <mzanetti> trying to understand the comment...
[10:37] <anpok_> without that the system thinks that only the first pointer is pressed or released
[11:42] <mzanetti> anpok_: confirming that your patch works. Thanks a bunch!
[11:49] <anpok_> cool
[11:53] <greyback> anpok_: thank you!
[14:33] <dobey> AlbertA: hi!
[14:33] <dobey> AlbertA: have you been able to make any progress on https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1337481 ?
[14:34] <AlbertA> dobey: I was out for us holidays...but I'm back now, I will resume looking at this
[14:35] <dobey> AlbertA: ok, thanks
[15:06] <racarr> Morning
[15:47] <alan_g> AlbertA: I think I've a working deadlock free observers implementation. I am cleaning up the code (too much implementation in the wrong place). But you're welcome to preview: lp:~alan-griffiths/mir/spike-deadlock-free-observers
[15:47] <AlbertA> alan_g: cool I'll check it out
[15:51] <racarr> I think we may have some memory fragmentation issues...
[15:51] <racarr> My system got all swappy and slow
[15:51] <racarr> so I went to a VT...
[15:51] <racarr> where I realized I had been running
[15:51] <racarr> mir and a demo client for like
[15:51] <racarr> well since friday
[15:52] <racarr> then I killed Mir and everything got better
[15:52] <racarr> I wish I had thought to check some things but I had literally just gotten out of bed lol
[15:53] <racarr> alan_g: on cursor-spike-phase-7 were you just talking about the whitespace? (https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242)
[15:53] <AlbertA> racarr: reads like a mem leak too
[15:53] <alan_g> racarr: I was
[15:54] <racarr> alan_g: We have a seperate C style?
[15:54] <racarr> I couldn't find it in the style guide...
[15:54] <alan_g> I'm talking practice not documentation
[15:54] <racarr> AlbertA: Yeah...
[15:54] <racarr> alan_g: ?
[15:54] <racarr> a quick peek at the files shows both are
[15:54] <racarr> used
[15:55] <alan_g> Then never mind
[15:55] <racarr> :)
[15:56] <racarr> the wording of your comment made me paranoid that there was some strange different meaning of char const* const in C that I had forgotten
[15:56] <racarr> lol
[15:58] <kdub_> racarr, while we're on the topic of spike-7
[15:58] <kdub_> I guess, once we support the custom uploading can we remove the names?
[16:00] <greyback> racarr: hey you reviewed https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320 - you had 2 main issues. One was that a comment (about the event struct conversion) was removed, which I put back. What was the other? I can't find it in my logs now
[16:02] <racarr> kdub_: I don't think so...where would the client get the system cursor images then?
[16:02] <racarr> kdub_: I mean we could replicate the system under X where you use an external library and a strange undocumented series of names
[16:02] <racarr> to load ARGB data for you
[16:03] <kdub_> well, I was going to say the external library, without the undocumented/strange stuff
[16:04] <racarr> We would have to make this library though, because xcursor is strange
[16:04] <racarr> so why not have it in mir?
[16:04] <kdub_> like, it seems strange to me that mir just helps with the theming for cursors
[16:05] <kdub_> maybe I'm just asking whats the plan for how much theming mir will be responsible for
[16:05] <kdub_> like the same issue exists for window borders
[16:05] <kdub_> and stuff like that
[16:05] <racarr> mm
[16:06] <kdub_> it seems (since mir is a library) that those concerns are different enough that a theming sort of helper library would be justified
[16:06] <racarr> the cursor theme is a little different
[16:06] <kdub_> like it could even be libmirtheming.so and live in tree
[16:06] <racarr> unlike the initial proposals...you see how its landed
[16:06] <kdub_> (talking past the immediate branch here)
[16:06] <racarr> we dont actually expose any theming
[16:06] <racarr> its just
[16:06] <racarr> a set of cursors with different meanings
[16:07] <racarr> and then we have an intree implementation that loads the default xcursor theme because thats something lots of shells may be interested in doing
[16:07] <racarr> but the actual themeing, i.e. choosing a theme or something is basically the shells responsibility
[16:08] <racarr> I mean...I guess if we did end up with more themeing stuff espescially borders, etc (can't imagine all the way atm)
[16:08] <racarr> libmirtheming would make sense
[16:08] <racarr> I think of the cursor names as more like the surface state enum though
[16:08] <racarr> if that makes any sense...
[16:09] <greyback> +1 for separate library from me. I don't see why core Mir should do anything more than have a method which lets a shell set an image as the cursor. Then the shell can use this helper library to get that image if it wants
[16:09] <racarr> well 1 because USC
[16:09] <racarr> should probably set the cursor in most configurations ...
[16:09] <racarr> I mean I guess USC could have the XCursor loader
[16:09] <greyback> not everyone will want to use USC
[16:10] <racarr> this isnt what the cursor names solve though...its just
[16:10] <racarr> right so if either USC or unity8 may need to load the cursors
[16:10] <racarr> the code should be in mir -.-
[16:10] <racarr> the names is just though
[16:10] <kdub_> right, I guess I'm talking at the next-step level
[16:10] <racarr> how does the client request
[16:10] <racarr> a "busy" (for example)
[16:10] <racarr> cursor
[16:10] <kdub_> the "spike-7" branch is okay, but I think that the next step should drive at chasing the specific cursor images out of the mir core
[16:11] <racarr> meh, maybe
[16:11] <racarr> I mean I thought about it right because
[16:11] <racarr> its obviously ugly
[16:11] <racarr> and obviously incorrect an always will be
[16:11] <racarr> i.e. there is no "This is the correct list of cursor names"
[16:11] <kdub_> like, the interested client can link to libmirtheming.so and use that, or if they are very interested in developing their own theme system, they can link to something else
[16:12] <racarr> this doesnt prevent that though
[16:12] <racarr> you could replace the_cursor_images with something
[16:12] <racarr> that themes as you want
[16:12] <racarr> but you can still interpret mir_cursor_default
[16:12] <racarr> as the default cursor from your theme
[16:12] <kdub_> sure, it doesn't prevent it, but it does make mir provide more
[16:12] <racarr> yes
[16:13] <racarr> I guess I just figured...I mean some part of ubuntu has to provide it
[16:13] <kdub_> right, and by 'mir' i really mean 'core mir'
[16:14] <racarr> maybe...
[16:14] <kdub_> sure, I agree... I just think its something that core mir shouldn't have (it can be in-tree under a different helpful theming stuff)
[16:14] <racarr> where to draw the line?
[16:14] <kdub_> like "i want to set a cursor image" or "this is my default image" seems generic
[16:14] <racarr> I mean, a shell is free to ignore surface states and implement its own system.
[16:15] <racarr> so should there be libmirshellstates
[16:16] <kdub_> I think there should be some sort of shell scratchpad, but I think that's a bit different topic
[16:16] <racarr> lol
[16:16] <kdub_> :D
[16:18] <racarr> im not really against some sort of mirtheming seperate thing I guess...just as far as I imagine it so far I think
[16:18] <racarr> I would rather just have it in mir (because its pretty harmless...) rather than have
[16:18] <racarr> a new thing with a name that has to be remembered and thought about
[16:18] <racarr> lol
[16:18] <racarr> greyback: Sorry um the
[16:18] <racarr> other thing was
[16:19] <racarr> greyback: l427
[16:19] <racarr> is a strange but I guess justified choice (danmdrader explained)
[16:19] <racarr> but it should maybe come with a comment about how that whole block only makes sense for tablet/phone (i.e. using maximized as restored)
[16:20] <kdub_> racarr, yeah, but really, people don't want what's in mir when it gets too specific
[16:20] <kdub_> like, 'here's a compositor for you, isn't it nice?' gets met with 'no, sorry, want to do my own thing'
[16:20] <kdub_> just seems 'cursor images' is something like that
[16:20] <greyback> racarr: it's an initial state that's overwritten before used? I guess it could be U_UNKNOWN_STATE
[16:21] <racarr> kdub_: Mmm...yeah its possible...
[16:21] <racarr> ill continue thinking
[16:21] <racarr> greyback: Yeah I think so...
[16:22] <racarr> greyback: ERr...unless windows
[16:22] <racarr> start on maximized
[16:22] <racarr> err
[16:22] <racarr> as minimized
[16:22] <racarr> before they are shown
[16:22] <racarr> and line 445
[16:23] <racarr> depends on it
[16:23]  * kdub_ just keeps thinking of the decorations/compiz situation :P
[16:23] <racarr> I feel like its fine with a comment that maximized is only the default for tablet or phones or something
[16:23] <greyback> racarr: you're right. Code bit clunky. Comment will do
[16:24] <racarr> :) thanks
[16:24] <racarr> besides that
[16:24] <racarr> it all looked good and left a comment on launchpad as thus
[16:26] <racarr> gosh I am so happy today
[16:26] <racarr> I bought a memory foam pillow
[16:26] <racarr> and slept the best ive slept in like a month
[16:26] <racarr> been having growing insomnia again
[16:27] <greyback> racarr: ok comment pushed
[16:27] <greyback> glad you're sleeping better
[16:27] <greyback> insomnia can be horrible, I suffered it a few years ago
[16:27] <racarr> Mm...I had it really bad as a kid and finally got it under control a few years ago so it was frustrating to see it return
[16:28] <racarr> I think in this case it was just back stuff though
[16:28] <racarr> and a better pillow will help a lot...maybe a new mattress
[16:28] <racarr> ...better office chair -.-
[16:29] <greyback> racarr: if you're happy, please mark approved
[16:29] <racarr> greyback: Oh hmm one more thing
[16:29] <greyback> racarr: omg an iWatch!
[16:30] <racarr> not sure of the deal with platform-api but
[16:30] <racarr> iWatch?
[16:30] <racarr> does it require
[16:30] <racarr> an soname bump or
[16:30] <racarr> some version must have to change right
[16:30] <greyback> sorry, bad apple "one more thing" jke
[16:30] <racarr> oh lol
[16:30] <racarr> just because its API change
[16:30] <racarr> ABI
[16:30] <racarr> change
[16:31] <greyback> soname should bump yeah, good catch. Should match package version really
[16:32] <racarr> I think THEN we are good though
[16:35] <AlbertA> uhhh...what happened to mir trunk?
[16:35] <AlbertA> it's gone...
[16:35] <AlbertA> camako: ^
[16:35] <racarr> lol
[16:35] <AlbertA> kgunn: ^
[16:36] <kgunn> oh no
[16:36] <alf_> mterry_: https://code.launchpad.net/~afrantzis/unity-system-compositor/grand-refactoring-first-steps/+merge/226000
[16:36] <kgunn> AlbertA: seems its still there....maybe series funny biz
[16:36] <kgunn> but this is there
[16:36] <kgunn> https://code.launchpad.net/~mir-team/mir/utopic
[16:37] <greyback> racarr: pushed
[16:37] <AlbertA> ok, I guess we had an alias before? lp:mir => lp:mir/utopic ?
[16:38] <alf_> mterry_: please check whether the session switching tests I introduced match the expectations we have for USC
[16:38] <racarr> alf_: Sounds grand
[16:38] <kgunn> AlbertA: yeah...we need to link lp:mir-team/mir/utopic to lp:mir
[16:38] <kgunn> weird...
[16:38] <racarr> ;)
[16:40] <racarr> greyback: Looks good...approve on launchpad
[16:40] <greyback> racarr: thank you
[16:40] <AlbertA> alf_: yey tests in USC !
[16:41] <racarr> brb more breakfast
[16:42] <alf_> AlbertA: only unit tests for one component (although central), but it's a start
[16:43] <alf_> AlbertA: do you get emails about USC MPs?
[16:43]  * alf_ wonders if I should add mir-team to the reviewers
[16:43] <AlbertA> alf_: nope
[16:54] <AlbertA> alan_g: ok, so if I understand correctly in the deadlock free branch, observers are now a linked list of ListItems and a custom lock that allows multiple concurrent readers but only one writer at any one time...
[16:55] <AlbertA> alan_g: and allows a reader to become a writer if it's in the same thread context
[16:55] <alan_g> AlbertA: that's the idea
[16:56] <alan_g> Also the linked list is a "grow only" structure (nodes are only deleted on destruction)
[17:00] <AlbertA> alan_g: ok, to avoid allocation overhead?
[17:01] <alan_g> AlbertA: to avoid the "current" node being removed or repurposed
[17:02] <AlbertA> alan_g: ahh
[17:02] <alan_g> AlbertA: hang on - I'm pushing a cleaner version of the code.
[17:02] <racarr> nice technique...:)
[17:04] <alan_g> AlbertA: I'm at EOD - if you want to grab the code and run with it feel free. If you don't have time I'll get back to it tomorrow.
[17:06] <AlbertA> alan_g: sure
[17:12] <camako> kgunn, AlbertA, yea the alias is not right
[17:12] <camako> any more
[17:13] <camako> kgunn, we (duflu/Alan_g/others) want lp:mir to point to devel
[17:13] <kgunn> camako: ack...i won't touch a thing....
[17:13] <camako> kgunn, and want the distro to pull from lp:~mir-team/mir/utopic
[17:13] <camako> kgunn, dunno if this is possible
[17:14] <kgunn> camako: right...i was going to say, you might need to talk to "someone"....that used to be didrocks...but he's since moved away from that job
[17:14] <kgunn> sil2100 would be the next person i would speak to...
[17:14] <kgunn> but i thikn their machinary needs lp:mir to be trunk...(this is an ancient problem)
[17:17]  * kgunn realizes we're overdue for our quarterly "can't we have trunk not be distro target" discussion
[17:17] <kgunn> discussion...or inquistition
[17:17] <camako> kgunn, we should let duflu loose on 'em
[17:18] <kgunn> exactly
[17:19] <camako> kgunn, currently lp:mir is an alias to the "development focus" branch
[17:19] <camako> which is now mir/0.5
[17:19] <camako> but it has no corresponding branch
[17:20] <camako> so it's difficult to set up the branches in a way that makes sense
[17:20] <camako> for our development
[17:20] <kgunn> yeah
[17:20] <kgunn> which is why it was the way it was
[17:22]  * camako thinks we'll deal with it in the next release
[18:48] <bregma> is there now power management in Mir 0.4?
[18:50] <racarr> Lunnch
[18:55] <kdub_> bregma, not in mir, although iirc, that has shifted to USC recently
[18:55] <kdub_> AlbertA can probably give better dates around when that happened
[18:56] <bregma> hmm, well, it's crept in somewhere and requires I reboot the desktop every 5 minutes because there's no wake support in the Unity 8 shell.
[18:57] <bschaefer> greyback, were you able to get xmir working?
[18:58] <greyback> bschaefer: nope. I gave up and logged a bug https://bugs.launchpad.net/mir/+bug/1339001
[18:58] <bschaefer> greyback, good idea :)
[18:58] <greyback> bschaefer: things work on my intel machine, so guess it's nouveau issue
[18:58] <bregma> ahh, the power button works like on the phone, a little unexpected on a desktop system
[18:58] <bschaefer> greyback, yeah, sounds like a nouveau issue then ... strange has to be have been a recent push
[18:58] <bschaefer> bregma, like, holding the button to turn it on?
[18:59] <bregma> bschaefer, yes, just like the phone
[18:59] <bregma> and, the power-down timeout is seems like about 30 seconds
[18:59] <bregma> also a little unexpected on a desktop
[18:59] <bschaefer> o wow, thats a long time to hold it
[18:59] <bschaefer> yeah
[18:59] <bschaefer> (at lease on a desktop)
[19:00] <bregma> no, you just tap the power button, the screen shuts off with no activity in 30 seconds
[19:01] <bregma> also, the second time you press the power button it just shuts down the whole machine ☹
[19:01]  * bschaefer does not know how phones work
[19:01] <bschaefer> my phone i have to hold the power button for ~30 seconds to shut it down
[19:01] <bregma> bschaefer, not shut down, wake up
[19:01] <bschaefer> otherwise it locks the screen
[19:01] <bschaefer> i see yeah
[19:16] <AlbertA> bregma: I updated USC to disable power key and inactivity handling with xmir
[19:16] <AlbertA> bregma: bu tthis is with unity 8 desktop? So it still uses usc wrapper to start up unity-system-compositor?
[19:17] <bregma> what is usc wrapper?
[19:17] <AlbertA> in touch
[19:17] <AlbertA> usc-wrapper is the one that lightdm will call to startup unity-system-compositor
[19:18] <AlbertA> for xmir, there's another wrapper which lives in tree in unity-system-compositor
[19:18] <bregma> that's new to me
[19:18] <AlbertA> I modified that last thursday to avoid the power key/inactivity stuff for xmir
[19:18] <bregma> what's with the sudden support for xmir?  who uses it?
[19:19] <AlbertA> bregma: so do you know how usc get's started for unity8 desktop?
[19:19] <bregma> lightdm starts u-s-c:  if there have been mods to have it do something special for the phone they didn't get publicized on the channels i follow
[19:20] <AlbertA> bregma: directly? no wrapper script or anything?
[19:20] <bregma> that's the way it used to do it
[19:21] <AlbertA> this is what will be used for ubuntu-desktop-mir:
[19:21] <AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/unity-system-compositor.sleep
[19:21] <AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/10-unity-system-compositor.conf
[19:22] <bregma> what is ubuntu-desktop-mir and how does it relate to the stuff currently in use in the Unity 8 desktop?
[19:22] <AlbertA> bregma: I don't know how it relates, I just know we use that for xmir
[19:23] <AlbertA> i.e. you install ubuntu-desktop-mir and you get xmir with unity7
[19:23] <bregma> what is xmir used for?
[19:23] <racarr> adventure
[19:23] <bregma> we do not support Unity 7 running that way
[19:23] <racarr> its "available for testing"
[19:26] <bregma> all I know is if you installed ubuntu-desktop-mir it would break OpenGL and my team would have to spend time supported people with broken systems
[19:26] <AlbertA> bregma: ok let's get back to the core issue
[19:27] <AlbertA> bregma: Is it unity8-desktop-session that has the lightdm confs?
[19:29] <bregma> AlbertA, yes indeed
[19:30] <AlbertA> bregma: I don't see unity-system-compositor there though...
[19:32] <bregma> AlbertA, no, because lightdm knows how to configure it automatically ... although if I can add a wrapper, I'd be happy
[19:33] <AlbertA> bregma: oh I see...well all we need is to set the cmd line arg: --disable-inactivity-policy=true
[19:33] <bregma> evidently the ability has been there for a while, now I look through the code
[19:33] <bregma> I shall play with this until usability is restored
[19:34] <AlbertA> bregma: well actually...usc may need more changes,
[19:35] <AlbertA> bregma: we need different policies I guess
[19:35] <AlbertA> bregma: because I assume you still need inactivity to take effect
[19:35] <AlbertA> bregma: but wakeups should occur with mouse or keyboard events, not power key
[19:36] <bregma> AlbertA, that will require support from the Shell, and it's not on the near-term radar
[19:36] <AlbertA> bregma: ok
[19:38] <AlbertA> bregma: well ping me if I can help further...
[19:38] <bregma> sure thing
[20:53] <racarr> the cursor renderable needs to support padding the image if the cursor buffer is larger than the image
[20:53] <racarr> i.e. on some gbm where its always 64x64
[20:53] <racarr> like mgm::Cursor does now
[20:53] <racarr> the thing is...it should also support multiple pixel formats now.
[20:54] <racarr> I guess I am just wondering if its appropriate to link in pixman
[20:54] <kdub_> groan
[20:54] <kdub_> :)
[20:54] <kdub_> nothing against pixman :)
[20:55] <kdub_> but once we do that... why not libjpeg and  and libpng
[20:57] <anpok> hm recently saw a patch that allows fantastic 128x128 for kaveri gpus..
[20:57] <kdub_> I probably wouldn't mind libmirhelpfultheming.so linking to things like that though
[20:58] <racarr> lol
[20:58] <racarr> anpok: Yes hence most. the thing is just that the cursor renderable buffer may not be the same size
[20:58] <racarr> as the cursor
[20:59] <racarr> nvm im dumb. for some reason I thought I was going to have to specialize the padding code for different
[20:59] <racarr> pixel formats
[20:59] <racarr> but
[20:59] <racarr> transparent
[20:59] <racarr> is the same everywhere...
[20:59] <racarr> *facepalm*