| kgunn | duflu: 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 |
|---|---|---|
| kgunn | granted choosing that route, we would feature starve those on trusty...but this is how most projects in my experience work | 01:56 |
| kgunn | if you want new features, move fwd | 01:56 |
| duflu | kgunn: I actually meant keep the HEAD buildable with trusty. But RAOF's libinput plans might make that impossible in the end | 01:56 |
| RAOF | Not really. | 01:56 |
| kgunn | duflu: yeah, i guess i am thinking....its "not that bad" | 01:56 |
| duflu | which is fine... there's a lot in flux | 01:56 |
| RAOF | Although you won't be able to build the libinput driver on trusty, of course :) | 01:56 |
| duflu | I mean if you want people to get involved in your project it has to be usable on a stable platform. That's obviously the LTS | 01:57 |
| duflu | But maybe we can't quite guarantee that this cycle | 01:57 |
| duflu | Getting input improved is more important that retaining trusty support, IMHO | 01:58 |
| kgunn | i think that's too strong a statement...if people want to get involved, they're welcome to be on the latest with us | 01:58 |
| kgunn | granted, this might be inconvenient for some... | 01:59 |
| kgunn | and it would be nice to do so of course | 01:59 |
| duflu | You'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 either | 01:59 |
| kgunn | mir dev....typical user ? :) | 02:00 |
| duflu | Then again, we may have build-from-source instructions to keep trusty going | 02:01 |
| duflu | I'm sure libinput is buildable | 02:01 |
| kgunn | duflu: last one before i disappear...i can tag at will for 0.1.9 right ? | 02:03 |
| kgunn | btw, landing is at a stand still...no such thing as "U" yet | 02:03 |
| kgunn | :) | 02:03 |
| duflu | kgunn: I highly recommend against it. The regressions are now visible and have fixes on the way | 02:03 |
| kgunn | duflu: ok, no problem... | 02:03 |
| duflu | On the plus side, 0.1.8 was tagged at a perfect time and has no regressions :) | 02:04 |
| kgunn | com' on...we planned it :P | 02:05 |
| kgunn | duflu: hey, besides this one... | 02:05 |
| kgunn | https://bugs.launchpad.net/mir/+bug/1308941 | 02:05 |
| ubot5 | Launchpad bug 1308941 in Mir "[regression] mir_demo_server_shell crashes on display resume [what(): Invalid or inconsistent display configuration]" [High,Triaged] | 02:05 |
| kgunn | what else are you thinking is a must fix regression ? ( i reviewed the bugs..but nothing jumped out) | 02:05 |
| duflu | kgunn: Nope. 0.1.8 predates the regression :) | 02:05 |
| duflu | They're all bug-never-released, which is good | 02:06 |
| duflu | kgunn: Mostly bug 1308843, but there's a list in https://launchpad.net/mir/+milestone/0.1.9 | 02:07 |
| ubot5 | bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress] https://launchpad.net/bugs/1308843 | 02:07 |
| kgunn | duflu: nice!..thanks for the hygiene, easy to see | 02:08 |
| kgunn | ok...night guys... | 02:12 |
| kgunn | duflu: 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 devices | 02:14 |
| racarr__ | either I already did and the keyboard is working perfectly | 02: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 |
| RAOF | racarr__: I'd do it by removing xf86-input-evdev and xf86-input-synaptics from the search paths of your fancy new Xserver. | 02:47 |
| RAOF | racarr__: That'll do it for sure; we should, however, patch out the input detection logic in the XMir case. | 02:48 |
| RAOF | But 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 | ||
| mlankhorst | ooh fancyyy | 07:46 |
| duflu | ? | 07:48 |
| mlankhorst | inputless xserver :) | 07:51 |
| duflu | Oh that | 07:56 |
| duflu | I hate it when Europe wakes up | 07:56 |
| duflu | Oh, hi Europe! | 07:56 |
| duflu | :) | 07:56 |
| mlankhorst | I don't think canonical would approve of me sleeping all day :P | 07:57 |
| mlankhorst | during work time | 07:57 |
| RAOF | I think they'd be fine with it, as long as you worked all night! | 07:57 |
| duflu | Bah it's fine. I have a plan to finish at a sane hour tonight | 07:58 |
| RAOF | Speaking of sane hours, 6pm says EOD! | 07:58 |
| * duflu waves to RAOF | 07:59 | |
| mlankhorst | lies :P | 07:59 |
| duflu | alf_: 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 |
| duflu | alf_: r1546... but maybe I got it backwards? | 08:19 |
| duflu | alf_: Oh, that's not it. The issue is just setting current_mode_index=<invalid> on resume | 08:22 |
| duflu | That's more straightforward | 08: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 cleared | 08:23 |
| alf_ | duflu: not sure how to best handle that, we update the configuration information using the information given by the hardware | 08:25 |
| duflu | alf_: I think it needs to remember the current mode. Because guessing on resume with preferred_mode could easily be wrong | 08: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 |
| duflu | alf_: I'm testing with simple pause and resume. How should demo-shell remember the mode between Alt+P's | 08:26 |
| duflu | ? | 08:26 |
| duflu | Previously it was just remembered in the display structure | 08: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 |
| duflu | alf_: 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 structure | 08:30 |
| duflu | Never mind, I'll either find a way or cook dinner early | 08: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_g | alf_: duflu can we just hash some display attributes to detect changes vs on/off? | 08:33 |
| duflu | alan_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 value | 08:33 |
| duflu | So a dumb shell can set outputs off/on/off/on blindly | 08:34 |
| alan_g | duflu: I think alf_ is worried that the old value could be wrong if the device changed. | 08:35 |
| duflu | alan_g: Which is still validated, and better than what we have now (invalid --> crash) | 08:35 |
| alan_g | ack | 08:36 |
| alan_g | duflu: any thoughts about this approach: https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/216332 | 08:39 |
| duflu | alan_g: None at all. I'm involved in too many reviews again so won't get involved | 08:40 |
| alan_g | duflu: np | 08: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 Disp | 08:44 |
| duflu | alf_: It's actually an easy fix it seems. The off display still has a persistent structure and ID. Only challenge to do a regression test | 08: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 | ||
| mterry | Is greyback on vacation? | 14:06 |
| alan_g | I was wondering that too | 14:08 |
| ogra_ | lying in the sun and turnuing into brownback :) | 14:10 |
| racarr__ | Morning | 14:53 |
| anpok | maybe for some people :P | 14:56 |
| racarr__ | anpok: Wait are you implying the other things on IRC are also people?!?! | 14:56 |
| racarr__ | seems I owe some apologies | 14:56 |
| racarr__ | :p | 14:56 |
| anpok | hm yah proving that gets harder every day | 14:56 |
| racarr__ | haha thats what | 14:57 |
| racarr__ | sprints are for | 14: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 | ||
| RAOF | Mornin all. | 23:32 |
| RAOF | racarr__: What up, dude! | 23:32 |
| racarr__ | Morning! | 23:35 |
| 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 and | 23:37 |
| racarr__ | not getting duplicate key events I assume its not working lol | 23:37 |
| racarr__ | presumably some field of one of the device configuration structs needs to be set to 9 instead | 23:38 |
| racarr__ | of 7 | 23:38 |
| racarr__ | yeah its definitely not working | 23:46 |
| RAOF | Heh. | 23:50 |
| RAOF | Are you running your XMir as root? | 23:51 |
| RAOF | Because 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 um | 23:53 |
| racarr__ | I tried adding 11 to keycode though | 23:54 |
| racarr__ | and everything is still good | 23:54 |
| racarr__ | so its certainly not my keyboard events | 23:54 |
| racarr__ | going anywhere | 23:54 |
| racarr__ | QueueKeyboardEvents is being called, xf86PostKeyboardEvent, etc... | 23:54 |
| racarr__ | just need to read some code... | 23:54 |
| RAOF | Heh. | 23:57 |
| RAOF | --prefix=$HOME/.local. It's the way of the future! | 23:57 |
| racarr__ | o maybe | 23:58 |
| racarr__ | I actually built debs this time lol | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!