[06:49] <robert_ancell> RAOF, with nested X, can acceleration easily pass through now?
[06:49] <robert_ancell> And is the double IPC overhead not a major issue?
[06:49] <RAOF> I'd be astounded if it was.
[06:50] <RAOF> I mean, it'll be an overhead, but anything that's actually doing appreciable IPC with X is already a lost cause.
[06:51] <RAOF> And, yes; Xephyr is glamor-accelerated now and I believe supports GLX, too.
[06:51] <robert_ancell> Nice
[06:52] <robert_ancell> RAOF, how about window management? Do you need a special WM in the child X to have the correct behaviour?
[06:52] <RAOF> Yes, we'd need that.
[06:53] <robert_ancell> That is the hard problem I guess :(
[06:53] <RAOF> Indeed.
[06:53] <RAOF> One we've committed to solve, though.
[06:53] <robert_ancell> For U8, but not U7
[06:54] <RAOF> The solution for U8 could *be* the solution for U7
[06:55] <robert_ancell> RAOF, do we have a dedicated WM project now?
[06:56] <RAOF> No idea.
[08:46] <duflu> greyback_: I haven't (successfully) set up a test of U8 with this fix yet, but do you think QtMir might need fixing similarly? https://code.launchpad.net/~mir-team/mir/fix-1528109/+merge/291984
[08:47] <duflu> Unity8 is definitely broken in the same way. I'm just wondering if it needs a separate fix
[08:48] <greyback_> checking
[08:51] <greyback_> duflu: I don't think it is the same issue. From a cursory glance (pun intended) our cursor code doesn't assume integer movements
[08:52] <duflu> greyback_: Cool. Fingers crossed then Mir 0.23 is all it needs
[08:52] <duflu> Mir 0.22 I mean
[08:52] <greyback_> ack, thanks
[09:19] <duflu> greyback_: On that note, does U8 have its own acceleration curve now? Seems like we should not have two because that's resampling the resampled
[09:19] <greyback_> duflu: it does not
[09:19] <duflu> greyback_: If you want, I would prefer U8 did it and Mir just dealt with raw unmodified input coords
[09:20] <duflu> That would solve some more libinput regressions
[09:21] <duflu> Or Mir could just set a more sane default (off) then libinput's default (on)
[09:21] <greyback_> duflu: I don't see why we'd not use libinput's accel stuff.
[09:21] <duflu> libinput's acceleration curve is ugly and still causes bugs
[09:21] <greyback_> but it's customizable IIRC
[09:21] <duflu> Yeah, Mir could just set it to 'off'
[09:22] <greyback_> sure, but why reinvent if we can get libinput to do what we want
[09:22] <duflu> Its first derivative is not continuous.
[09:22] <duflu> which I think is a big part of the problem
[09:23] <duflu> Turning it off would return us to perfect and accurate mouse movement (Unity7 style)
[09:24] <greyback_> or we could work with upstream so that everybody gets that
[09:25] <duflu> More difficult to convince people their design sucks than just of some bug
[09:25] <greyback_> more work for us to take on entire burden of input processing
[09:26] <duflu> We actually don't need any any more. Since the resampling bug (recently fixed) was just a bug... that fix remains and "acceleration" of any sort is no longer required
[09:28] <greyback_> I don't understand. Why isn't pointer accel needed? It will be a user-configurable setting eventually
[09:28] <duflu> greyback_: Absolutely user configurable. I'm just suggesting make the default "none" instead of some weird curve. So it's exactly like Unity7
[09:29] <duflu> Which really is a discussion for mir-team
[09:30] <greyback_> duflu: I'm ok if you want to disable it in libinput. I'm not ok with reimplementing it in unity8, if libinput would do the job with some tweaking
[09:31] <duflu> greyback_: That's OK, I just feared U8 already did some
[09:31] <greyback_> nope
[09:31] <duflu> There are sliders
[09:31] <duflu> which do nothing
[09:33] <greyback_> duflu: sliders in the settings app? I believe they'll talk to USC which will configure libinput
[09:33] <duflu> Cool
[09:33] <greyback_> (not the final solution ofc)
[09:33] <duflu> Better than expected
[09:34] <duflu> greyback_: Why two? They're not labelled
[09:34] <greyback_> duflu: I honestly don't know, you'd need to ask settings app guys
[16:01] <n1md4> hi.  i have a gtx980m and nvidi-364 driver.  when i attempt to login to mir / unity 8 it somewhat hangs at the login screen.  does this type of problem sound familiar to anyone?
[16:02] <n1md4> worth reporting a bug?  is so where.
[16:02] <n1md4> if so, where* even
[16:02] <ogra_> since when does Mir work with proprietary drivers ?
[16:03] <n1md4> hah
[16:03]  * ogra_ thought it only works with nouveau
[16:03] <n1md4> http://phoronix.com/scan.php?page=news_item&px=NVIDIA-364.12-Linux
[16:03] <n1md4> :)
[16:03] <n1md4> i suppose, just because something is 'supported' doesn't yet mean it works.
[16:03] <ogra_> ah
[16:04] <ogra_> well, but how would they test the support then ? :)
[16:04] <alan_g> n1md4: there's work in progress, but not there yet
[16:04] <n1md4> ogra_: no idea :)
[16:05] <ogra_> there you have your answer though
[16:05] <n1md4> alan_g: thanks, i did check in here the other day, may have been you i spoke with then.  what's the best way to keep up to date with this?  would it be enough to check for ubuntu updates and catch when mir is in that list?  or is there a more efficient way.
[16:07] <alan_g> n1md4: Mir releases are announced on Mir-devel@lists.ubuntu.com (if you don't mind the traffic)
[16:07] <n1md4> thanks, alan_g, i'll check it out