kgunnduflu: wrt "keeping mir working with trusty"... at first, i felt like "yes we should"...but the more i thot about it, there will always be a mir version in trusty, and people can get that code....01:55
kgunngranted choosing that route, we would feature starve those on trusty...but this is how most projects in my experience work01:56
kgunnif you want new features, move fwd01:56
duflukgunn: I actually meant keep the HEAD buildable with trusty. But RAOF's libinput plans might make that impossible in the end01:56
RAOFNot really.01:56
kgunnduflu: yeah, i guess i am thinking....its "not that bad"01:56
dufluwhich is fine... there's a lot in flux01:56
RAOFAlthough you won't be able to build the libinput driver on trusty, of course :)01:56
dufluI mean if you want people to get involved in your project it has to be usable on a stable platform. That's obviously the LTS01:57
dufluBut maybe we can't quite guarantee that this cycle01:57
dufluGetting input improved is more important that retaining trusty support, IMHO01:58
kgunni think that's too strong a statement...if people want to get involved, they're welcome to be on the latest with us01:58
kgunngranted, this might be inconvenient for some...01:59
kgunnand it would be nice to do so of course01:59
dufluYou're asking the typical user to replace what is possibly their only PC with a pre-release OS. I don't think that's ideal but it's nothing new either01:59
kgunnmir dev....typical user ? :)02:00
dufluThen again, we may have build-from-source instructions to keep trusty going02:01
dufluI'm sure libinput is buildable02:01
kgunnduflu: last one before i disappear...i can tag at will for 0.1.9 right ?02:03
kgunnbtw, landing is at a stand still...no such thing as "U" yet02:03
duflukgunn: I highly recommend against it. The regressions are now visible and have fixes on the way02:03
kgunnduflu: ok, no problem...02:03
dufluOn the plus side, 0.1.8 was tagged at a perfect time and has no regressions :)02:04
kgunncom' on...we planned it :P02:05
kgunnduflu: hey, besides this one...02:05
ubot5Launchpad bug 1308941 in Mir "[regression] mir_demo_server_shell crashes on display resume [what(): Invalid or inconsistent display configuration]" [High,Triaged]02:05
kgunnwhat else are you thinking is a must fix regression ? ( i reviewed the bugs..but nothing jumped out)02:05
duflukgunn: Nope. 0.1.8 predates the regression :)02:05
dufluThey're all bug-never-released, which is good02:06
duflukgunn: Mostly bug 1308843, but there's a list in https://launchpad.net/mir/+milestone/0.1.902:07
ubot5bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress] https://launchpad.net/bugs/130884302:07
kgunnduflu: nice!..thanks for the hygiene, easy to see02:08
kgunnok...night guys...02:12
kgunnduflu: i'll keep an eye on those bugs and won't tag until then...02:12
racarr__RAOF: So how do I stop x from opening the real input devices02:14
racarr__either I already did and the keyboard is working perfectly02:14
racarr__or I didnt (seems pretty likely)02:14
racarr__and my events are dissapearing into QueueKeyboardEvent because of some strange device configuration error (totally plausible)02:15
RAOFracarr__: I'd do it by removing xf86-input-evdev and xf86-input-synaptics from the search paths of your fancy new Xserver.02:47
RAOFracarr__: That'll do it for sure; we should, however, patch out the input detection logic in the XMir case.02:48
RAOFBut we don't yet.02:48
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mlankhorstooh fancyyy07:46
mlankhorstinputless xserver :)07:51
dufluOh that07:56
dufluI hate it when Europe wakes up07:56
dufluOh, hi Europe!07:56
mlankhorstI don't think canonical would approve of me sleeping all day :P07:57
mlankhorstduring work time07:57
RAOFI think they'd be fine with it, as long as you worked all night!07:57
dufluBah it's fine. I have a plan to finish at a sane hour tonight07:58
RAOFSpeaking of sane hours, 6pm says EOD!07:58
* duflu waves to RAOF07:59
mlankhorstlies :P07:59
duflualf_: You changed the meaning of conf_output.used to sometimes be false even for a display in use (but off). Is that a good idea/required?08:14
alf_duflu: where did I do that?08:19
duflualf_: r1546... but maybe I got it backwards?08:19
duflualf_: Oh, that's not it. The issue is just setting current_mode_index=<invalid> on resume08:22
dufluThat's more straightforward08:22
alf_duflu: hmm, yeah, so because of the change to not have a DisplayBuffer (and the underlying framebuffer object) for displays that are off, the mode is cleared08:23
alf_duflu: not sure how to best handle that, we update the configuration information using the information given by the hardware08:25
duflualf_: I think it needs to remember the current mode. Because guessing on resume with preferred_mode could easily be wrong08:25
alf_duflu: What about the case that you power off the screen, then unplug it and plug in a new one? That is, how can we differentiate when to remember and when to not remember?08:26
duflualf_: I'm testing with simple pause and resume. How should demo-shell remember the mode between Alt+P's08:26
dufluPreviously it was just remembered in the display structure08:27
alf_duflu: the point is that when we request the configuration, we shouldn't make any assumptions about it, because it can change because of events external to mir (like someone pluging things in or out)08:29
duflualf_: Yeah I know, but more common is a simple suspend/resume... And it makes no sense to move responsibility for saving just one attribute outside of the structure08:30
dufluNever mind, I'll either find a way or cook dinner early08:31
alf_duflu: I would be OK with that as long as it is safe to do so (e.g. the set mir_power_mode_off, unplug screen, plug a new one scenario)08:31
alan_galf_: duflu can we just hash some display attributes to detect changes vs on/off?08:33
duflualan_g: The field that stores the current_mode is presently invalid. All we need to do is not set it to invalid and keep its old value08:33
dufluSo a dumb shell can set outputs off/on/off/on blindly08:34
alan_gduflu: I think alf_ is worried that the old value could be wrong if the device changed.08:35
duflualan_g: Which is still validated, and better than what we have now (invalid --> crash)08:35
alan_gduflu: any thoughts about this approach: https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/21633208:39
duflualan_g: None at all. I'm involved in too many reviews again so won't get involved08:40
alan_gduflu: np08:41
alf_duflu: The same would happen with the new scheme too, if we don't do things properly... an invalid value in the configuration (e.g. mode 4 out of the 3 modes of the new monitor) will cause the same crash. Anyway, it may not be a problem really, because when a screen is unplugged we handle the event internally and update the configurations. So, to be safe we need to serialize all display conf changes (incl. power on/off) with our main loop, so probably an Disp08:44
duflualf_: It's actually an easy fix it seems. The off display still has a persistent structure and ID. Only challenge to do a regression test08:52
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
=== tvoss is now known as dvoss
=== alan_g is now known as alan_g|lunch
=== dvoss is now known as tvoss
=== alan_g|lunch is now known as alan_g
mterryIs greyback on vacation?14:06
alan_gI was wondering that too14:08
ogra_lying in the sun and turnuing into brownback :)14:10
anpokmaybe for some people :P14:56
racarr__anpok: Wait are you implying the other things on IRC are also people?!?!14:56
racarr__seems I owe some apologies14:56
anpokhm yah proving that gets harder every day14:56
racarr__haha thats what14:57
racarr__sprints are for14:57
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader|afk
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== chihchun is now known as chihchun_afk
=== bschaefer_ is now known as bschaefer
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== NoNameYet_xnox is now known as xnox
RAOFMornin all.23:32
RAOFracarr__: What up, dude!23:32
racarr__Nothing much...just getting back to xmir soon....new scene observer...maybe cursor part 1 can land now then I will rebase the rest.23:36
racarr__xmir is still where it is yesterday...things getting as far as QueueKeyboardEvents...but as im not unloading the default drivers and23:37
racarr__not getting duplicate key events I assume its not working lol23:37
racarr__presumably some field of one of the device configuration structs needs to be set to 9 instead23:38
racarr__of 723:38
racarr__yeah its definitely not working23:46
RAOFAre you running your XMir as root?23:51
RAOFBecause if you're not then the other input devices wouldn't actually be getting opened due to permissions.23:53
racarr__I am so it can write to the log file aha um23:53
racarr__I tried adding 11 to keycode though23:54
racarr__and everything is still good23:54
racarr__so its certainly not my keyboard events23:54
racarr__going anywhere23:54
racarr__QueueKeyboardEvents is being called, xf86PostKeyboardEvent, etc...23:54
racarr__just need to read some code...23:54
RAOF--prefix=$HOME/.local. It's the way of the future!23:57
racarr__o maybe23:58
racarr__I actually built debs this time lol23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!