=== chihchun_afk is now known as chihchun | ||
robert_ancell | RAOF, Can Xephyr be run in rootless mode? | 06:30 |
---|---|---|
RAOF | robert_ancell: I don't believe so, but could probably be made to do so easily. | 06:30 |
robert_ancell | RAOF, define "easily" :) | 06:31 |
RAOF | robert_ancell: Well, you'd get most of the way there by having a root window and just making it transparent? :) | 06:31 |
robert_ancell | RAOF, but then the window decorations would get very complicated for the internal WM | 06:32 |
RAOF | Yeah, is true. | 06:32 |
RAOF | So, my guess is “not *terribly* difficult or invasive”. | 06:33 |
RAOF | Well, maybe a *bit* invasive. | 06:33 |
RAOF | Say, less than a month all up? | 06:34 |
robert_ancell | For who? I think it would be more than that for me given my experience. Perhaps a RAOF+duflu team would do it in a month.. | 06:35 |
robert_ancell | RAOF, with XMir in rootless mode, how much work does the window manager need to do? The placement should all be done by the parent WM right? | 06:36 |
robert_ancell | I mean the WM that runs inside XMir | 06:36 |
RAOF | Yeah. | 06:36 |
RAOF | The end-state for XMir in rootless mode is that the X11-WM is basically nothing but a proxy to the external WM. | 06:37 |
RAOF | Needs to do a bit of translation for resizing and such. | 06:37 |
duflu | robert_ancell: Xmir -rootless completely throws away the window manager, and implements WM itself Mir-style | 06:38 |
robert_ancell | duflu, ah | 06:39 |
duflu | You could still run one, but it might conflict | 06:39 |
robert_ancell | So XMir on X would probably be the most working solution... | 06:39 |
duflu | robert_ancell: On X? | 06:39 |
robert_ancell | Mir has an X backend right? | 06:40 |
robert_ancell | (I'm kidding) | 06:40 |
duflu | robert_ancell: Yes it does exist, but that's fullscreen Mir server in an X window | 06:40 |
duflu | robert_ancell: Xmir -rootless implements its own XComposite-based window management. I know of no shell that handles it well yet, but also implemented a workaround for that too: Xmir -rootless -flatten which only asks the Mir shell to implement one window per app (which most Mir shells can handle) | 06:42 |
duflu | Umm, I mean -flatten uses XComposite | 06:43 |
duflu | So Xmir uses Xorg to do the compositing in software with -rootless -flatten | 06:44 |
duflu | Actually since widgets are windows, that's normal | 06:44 |
RAOF | It's not using the hardware-accelerated compositing path? | 06:53 |
duflu | Nope. Because that's actually very buggy, and not beneficial to pursue right now either | 06:54 |
RAOF | That seems unlikely? We're using the same glamor hardware-composited path on regular X. | 06:55 |
duflu | RAOF: armhf is set to always software anyway. Desktop is not | 06:55 |
duflu | That's why it works | 06:56 |
RAOF | That I can see; armhf glamor is unlikely to be awesomely well tested :) | 06:56 |
duflu | Hardware acceleration matters much more for GLX clients. However that's only really feasible with DRI (desktop hardware) | 07:00 |
duflu | And in all fairness, even software buffers are cached in hardware for most of their life, so performance is good | 07:00 |
RAOF | Right, but GPU composition is vastly faster than CPU composition on all hardware. | 07:04 |
RAOF | If you're actually *doing* any composition... | 07:04 |
duflu | RAOF: True, but "vastly" is still completely insignificant compared to even a single frame of lag. And we have several frames of lag. | 07:06 |
duflu | So that gets attention first | 07:06 |
RAOF | I don't think that's the case? | 07:07 |
RAOF | As evidenced by your discovery that your monitor introduces a 20ms delay that you were entirely unaware of. | 07:07 |
duflu | It is. Proof: Software rendering completes in well under 16ms even on mobile. Our buffering lag is closer to 90ms | 07:07 |
RAOF | But that's two different types of milliseconds :) | 07:08 |
duflu | RAOF: In user perception | 07:08 |
RAOF | But as long as rendering *is* maintaining 60Hz, lag is indeed a more interesting target. | 07:09 |
duflu | It is. Software rendering is very fast even on a phone (with the exception of the infamous OTA-10 regression) | 07:09 |
RAOF | Right. User perception is “30Hz is worse than a consistent 90ms of lag, even though frames containing my input reach the screen faster”. | 07:10 |
duflu | RAOF: Agreed, but that's not an issue. Also it would be irresponsible to pursue. Do you want Xmir working in 2015 as it was, or wait till 2017/2018? | 07:11 |
RAOF | Yeah, I'm agreeing with you. | 07:11 |
RAOF | As long as we're hitting frame deadlines, we don't *really* need to increase rendering performance. | 07:11 |
duflu | RAOF: Even still, less important than our other current performance focal points | 07:13 |
duflu | No one cares if you've made Xmir faster if you had to stop working on improving the performance of all of Unity8 | 07:14 |
zzarr | hello! does Mir software rendering work now? | 07:32 |
duflu | zzarr: In very very limited conditions. Depends what you're trying to do | 07:34 |
duflu | But mostly not | 07:34 |
zzarr | duflu, I'm not trying to do anything right now, it was just a general question | 07:35 |
duflu | We are making baby steps in other tasks that will help generic software rendering in future | 07:36 |
zzarr | nice | 07:37 |
zzarr | of course I still want to try to get Ubuntu with Mir running om my chromebook | 07:48 |
zzarr | it's vital that I can turn both the touch pad and keyboard off when flipping it | 07:49 |
zzarr | (ti's an Asus Chromebook Flip) | 07:50 |
zzarr | it's* | 07:50 |
anpok | so you want them to be gone.. so that unity8 discovers that there are not more desktop input device, so it would switch to the tablet ui? | 07:51 |
zzarr | anpok, exactly | 07:52 |
duflu | Do we need to test of integer wraparounds that will happen after the Sun engulfs the Earth? | 07:59 |
duflu | I guess we should assume Mir is running outside the solar system | 07:59 |
anpok | zzarr: hm we should have the necessary interfaces in mir | 08:01 |
anpok | zzarr: but you would need changes to unity-system-compositor to deal with that... detect the lid switch telling you the flip state?.. hm. | 08:02 |
zzarr | anpok, nice | 08:02 |
zzarr | anpok, I don't know | 08:02 |
anpok | sounds like hwdb in usc .. dmidecode.. have lots of rules for various devices.. | 08:03 |
anpok | oh i believe we do not expose the input device registy in the mir server api... but thats the smallest problem | 08:04 |
anpok | i thought about another interface to allow the compositor to filter out input devices.. | 08:04 |
zzarr | anpok, okey, sadly I don't know anything about that, I just have a vision that I one day can run Ubuntu/Mir on my laptop | 08:04 |
zzarr | well, a script telling mir/unity that it should enter tablet mode and one that tells it to enter desktop mode would be nice | 08:06 |
zzarr | are the input filtered or are they turned off? (hw) | 08:07 |
anpok | hm ... if you would tell an InputDevice to stop libinput would still read from evdev | 08:07 |
anpok | but thats an implementation detail.. because we use libinputs udev handling.. and turning it off and on again would require to retrigger scanning udev devices.. | 08:08 |
anpok | the reason for using that are also further implementation details in libinput itself .. because of historic reasons it does certain init steps only when you let it handle udev.. | 08:09 |
zzarr | I'm feeling I'm on thin ice... never mind you answered the question before I asked it | 08:10 |
anpok | is it important that evdev events are not consumed? | 08:10 |
anpok | believe me there is no ice | 08:10 |
zzarr | anpok, does evdev events trigger text on the screen? (keyboard inputs) | 08:12 |
anpok | well input events take a route through the system compositor down to the focused client i noone filters it along that line.. and the rendered results comes back to screen | 08:13 |
anpok | *if no one filters it | 08:13 |
zzarr | okey, in that case, yes it is important that it's filtered (the keyboard/mouse pad ends up on the backside when flipped) | 08:20 |
anpok | oh | 08:20 |
anpok | I thought the screen is rotated then closed | 08:20 |
zzarr | this image shows the form factor http://liliputing.com/wp-content/uploads/2015/03/asus-chromebook-flip_02.jpg | 08:26 |
robert_ancell | duflu, RAOF, I figure it's about time to propose XMir upstream. Any opposition? | 08:38 |
duflu | robert_ancell: Ha. I would not have except just landed an emergency fix from Chris Townsend today. Not sure how to test it | 08:38 |
robert_ancell | duflu, I expect upstream is not going to test it in any detail anyway, so shouldn't be a problem. | 08:39 |
duflu | Upstream would need Mir to complain about anything. So long as we don't break code outside our own dir | 08:39 |
robert_ancell | Exactly. And it seems to be in well self contained now | 08:40 |
* duflu is guessing there are lots of desktoppers in London | 09:06 | |
robert_ancell | Prague | 09:06 |
duflu | Close | 09:06 |
duflu | Closer than here | 09:06 |
robert_ancell | Yep | 09:06 |
duflu | robert_ancell: What venue? | 09:06 |
robert_ancell | Hotel | 09:06 |
duflu | robert_ancell: Erm, which? | 09:07 |
robert_ancell | https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjHiY7S_bDMAhVqAZoKHXi5DiYQFggdMAA&url=http%3A%2F%2Fprague.boscolohotels.com%2F&usg=AFQjCNGa9EmXsm9WPTU0TKXUdwLjaNbSvQ | 09:07 |
robert_ancell | ah, stupid google links | 09:07 |
robert_ancell | http://prague.boscolohotels.com/ | 09:07 |
alan_g | attente: I'm working through the window management issues in Mir. It looks like gtk-mir might the cause of lp:1445543 - I've updated the description with a specific case that seems to show Mir passing events to the client that are ignored, can you check what happens in gtk? | 11:14 |
attente | alan_g: hey, sorry. i got your message, but didn't have a chance to check yet | 11:19 |
alan_g | attente: np | 11:20 |
bregma | hey robert_ancell I was going to ask if there was any reason (like maybe an Intel incident) why we haven't upstreamed XMir... I guess my question has been answered | 11:45 |
bregma | are you willing to do the work? | 11:46 |
robert_ancell | bregma, yep | 11:46 |
bregma | great | 11:47 |
anpok_ | bregma: looked at our xkb mapping code.. | 11:50 |
anpok_ | the altGr problem could be caused by other problems | 11:51 |
robert_ancell | hmm, why can't I VT switch out of mir_demo_server anymore? | 11:51 |
bregma | anpok_, problems within Mir, or elsewhere? | 11:51 |
anpok_ | we seem to use the api wrong.. | 11:51 |
anpok_ | yeah mir client.. i finish up the nested stuff and verify that theory | 11:51 |
alan_g | robert_ancell: it should be possible - I do it a lot | 11:51 |
bregma | anpok_, OK, so still Mir but on the client library? | 11:52 |
anpok_ | yes | 11:52 |
bregma | k | 11:52 |
robert_ancell | alan_g, yeah, it used to work fine. But not working for me right now... alt+ctrl+backspace seems to quit it, but not mir_demo_server_minimal | 11:52 |
alan_g | robert_ancell: minimal doesn't install the quit handler | 11:53 |
robert_ancell | alan_g, is there any easy way to log the keyboard events? | 12:01 |
anpok_ | MIR_CLIENT_INPUT_RECEIVER_REPORT=log | 12:01 |
anpok_ | oh in a server? | 12:02 |
robert_ancell | anpok_, yeah, the server | 12:02 |
anpok_ | MIR_SERVER_INPUT_REPORT does some logging.. not sure if it contais key code | 12:02 |
anpok_ | *contains key codes | 12:02 |
robert_ancell | hmm, doesn't seem to | 12:03 |
robert_ancell | I'm wondering if it doesn't work because I need to hold down 'Fn' for my F keys | 12:03 |
robert_ancell | If I can get a log of keycodes that might help | 12:04 |
anpok_ | hm ok it does .. you should see "Received event .. type=EV_KEY code=<some number> value=0/1" | 12:05 |
=== alan_g is now known as alan_g|lunch | ||
anpok_ | when you set that env var to =log | 12:06 |
robert_ancell | I got nothing when I set MIR_SERVER_INPUT_REPORT=log | 12:06 |
robert_ancell | But mir_demo_server --print-input-events does something, but the output seems to overwrite so I can't read it | 12:06 |
robert_ancell | http://paste.ubuntu.com/16094191/ | 12:07 |
robert_ancell | Should the keycode always be 0? | 12:08 |
robert_ancell | The only scancodes seem to be alt, ctrl and backspace. i.e. nothing for Fn or the function keys | 12:10 |
anpok_ | yeah.. no scan to key code translation on the server | 12:10 |
anpok_ | ok thats.. odd.. | 12:11 |
robert_ancell | I wonder if the function keys are done with ACPI? | 12:12 |
robert_ancell | showkey suggests F2 is scancode 224, which is KEY_BRIGHTNESSDOWN | 12:17 |
anpok_ | aeh.. hm but neither libinput nor mir filters out keys | 12:18 |
anpok_ | robert_ancell: what does evtest say about the input devices that you have? | 12:22 |
robert_ancell | ah, KEY_F2 does work, but not in combination with alt+ctrl for some reason | 12:22 |
robert_ancell | ok, now with more careful testing, I am getting the event to show with --print-input-events, but still no VT switch | 12:27 |
robert_ancell | Seems the order in which I press 'Fn' matters | 12:28 |
robert_ancell | ah. I know what this is. The VT switching is done on /dev/console which for some reason stopped working in Xenial. This affected LightDM, so I switched to using /dev/tty0 which is what other things use (GDM, logind). | 12:31 |
robert_ancell | I'll make a merge proposal... | 12:32 |
=== alan_g|lunch is now known as alan_g | ||
=== dandrader is now known as dandrader|afk | ||
=== chihchun is now known as chihchun_afk | ||
=== dandrader|afk is now known as dandrader | ||
=== _morphis is now known as morphis | ||
robert_ancell | anpok, https://code.launchpad.net/~robert-ancell/mir/vt-tty0/+merge/293277 | 14:42 |
=== dandrader is now known as dandrader|bbl | ||
=== alan_g is now known as alan_g|EOD | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!