/srv/irclogs.ubuntu.com/2013/09/04/#ubuntu-mir.txt

* robert_ancell -> lunch00:51
RAOFrobert_ancell: When you get back we need to discuss how to proceed with Operation: Worst Thing Ever (ie: sideband pipe between usc and Xmir)01:02
RAOFduflu: You tracked down damage problems?01:12
dufluRAOF: Kind of, not really. I need to devote more hours to better learning XMir01:14
duflukdub: You're back? Congratulations by the way01:35
smspillazracarr: long shot, but still around ?01:50
dufluRAOF: ickle says he "pushed a patch" for the intel cache/lines issue with bypass. But I can't tell which commit(s) it was. Do you think... http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=47e718bf321f6fe80dc5f797f433b00bc8de91c7 ?01:55
robert_ancellRAOF, yes. I was also wondering how far from working the focus thing is - that would at least reduce the pressure for a less hacky solution01:56
RAOFduflu: It's all folded up into the single monolithic xmir commit, but yeah.02:12
RAOFduflu: It's a bit ugly; we should either work out how to unuglify it - probably by telling the DDX when bypass is in effect, rather than having it guess it.02:13
dufluRAOF: If you can get the bo flags then it's easy :/02:13
RAOFThe bo-flags are userspace only02:14
dufluRAOF: Oh, actually that wouldn't help. Most large surfaces are now SCANOUT even when not bypassed02:15
dufluRAOF: A surface attribute? Still ugly02:16
RAOFA buffer attribute.02:17
RAOFAs it has to be :)02:17
RAOFBecause SCANOUT is already a possible pessimisation in the non-bypass case.02:18
RAOFrobert_ancell: Oh, the focus thing is mostly ok. It works for single-head; I just need to work out what I do wrong in the multihead case.02:35
=== chihchun_afk is now known as chihchun
dufluRAOF: Sanity-check vladmir-upstreaming FTW?03:05
RAOFduflu: Yes.03:05
RAOFAlthough you'll want to pull the changes back to the ubuntu branch.03:05
RAOFBecause vladmir-upstreaming is based on master, which is an ABI bump ahead of us.03:06
dufluRAOF: Argh. Maybe I'll just keep working with apt-get source on saucy to minimize impact on the system...03:07
RAOFduflu: vladmir-upstream-base is the tag you want; it's easy to reproduce xmir.patch03:08
RAOFduflu: git diff vladmir-upstream-base..vladmir-upstreaming > debian/patches/xmir.patch03:08
dufluRAOF: When will that be upstreamed? Post 13.10?03:11
RAOFOnce it's broadly feature-complete.03:11
RAOFI think glx-bypass is the final piece of that.03:11
dufluRAOF: I can't see any guarantees about which portion of damage actually makes it to the swap_buffers. How can we be sure about the exact damage region that *really* got swapped?03:35
duflu... without waiting03:35
dufluOh, actually, maybe the answer is in the DDX...03:35
RAOFWhat do you mean? The drivers are responsible for passing a correct region into submit_rendering.03:36
RAOFAnd they're responsible for doing enough flushing that the fd submitted to Mir actually contains the rendering expected.03:36
dufluRAOF: Yes! OK so the answer is the region parameter to the submit. Ta.03:36
RAOFAs a practical matter, the DDXen all pass the region that they get passed in.03:38
* duflu -> lunch04:45
RAOFAh, good. Now with significantly less password-leakage-across-VT-switch!05:04
RAOFrobert_ancell: So, the XMir side of focus-thing works. The Mir side (drop focus on VT switch) hasn't landed yet as far as I can tell.05:25
robert_ancellRAOF, cool05:52
tvoss_robert_ancell, ping05:53
tvoss_robert_ancell, don't have broadband in the new house, yet05:53
robert_ancelltvoss_, ok, so not coming to meeting?05:53
tvoss_robert_ancell, trying, but don't know if it works, only 3G here :/05:54
robert_ancellhikiko, duflu, racarr, kdub, meeting05:58
robert_ancellduflu, should we close bug 1217262 invalid?06:18
ubot5bug 1217262 in Unity System Compositor ""sudo restart lightdm" always hangs/fails when using unity-system-compositor" [Undecided,Incomplete] https://launchpad.net/bugs/121726206:18
duflutvoss_: How did you go with Mir-native-OpenArena ?06:18
robert_ancellduflu, you may have been hitting the problem where u-s-c was left running due to the way it was launched with a shell script06:19
duflurobert_ancell: I think it might still be valid. We have something occasionally keeping DRM open and triggering bug 120663306:19
ubot5bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/120663306:19
duflu... but it's racy. If you stop, pause, start, then it's OK06:20
mlankhorstyeah of course it's racy..06:20
dufluAs mlankhorst keeps pointing out06:20
robert_ancellduflu, then is it better covered by that specific bug? The bug you filed is a bit vague and likely to attract random me toos06:20
mlankhorstunity-system-compositor needs to be completely dead before starting lightdm again :P06:20
duflumlankhorst: That should surely be solvable in upstart06:21
robert_ancellmlankhorst, right, and lightdm does wait for that. But there was a bug where it was launched by a shell script without exec and lightdm was killing the shell script and not realizing u-s-c was still running06:21
mlankhorstor we should start usc WAY early.. and make plymouth a client to usc..06:21
duflurobert_ancell: Incomplete bugs should be left to expire naturally due to inactivity I say06:21
duflu"Expire of natural causes"06:22
robert_ancellduflu, well, you filed this bug... why not just close and re-open if you see it again?06:22
duflurobert_ancell: I will retest for it now...06:22
duflurobert_ancell: Reproduced. Now a duplicate of bug 1206633 :)06:24
ubot5bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/120663306:24
robert_ancellduflu, awesome06:24
robert_ancellduflu, is bug 1216245 still applicable? afaik the demo shells don't need any special code for multi-monitor06:25
ubot5bug 1216245 in Mir "mir_demo_server_shell doesn't respond to hotplugging monitors" [Undecided,New] https://launchpad.net/bugs/121624506:25
duflurobert_ancell: Yes it's an issue and nice to have for testing. Just set Wishlist06:26
hikikoduflu, are you working on the bug: #1216522?06:33
ubot5bug 1216522 in XMir "XMir hung in xf86CrtcSetModeTransform()" [Critical,New] https://launchpad.net/bugs/121652206:33
duflurobert_ancell: I'm not sure having a completely broken display is only Medium... bug 121881506:33
ubot5bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Medium,Triaged] https://launchpad.net/bugs/121881506:33
robert_ancellduflu, change it :)06:34
robert_ancellI'm just doing a first cut for triaging, I'll re-look over high-med-critical and do them next06:34
hikikoquestion: I startx to have a 2nd window manager apart from unity and the events (like double click on desktop) are send to unity (wrong vt?) is this a bug or something expected?06:35
dufluhikiko: Yes, RAOF is working on that06:35
hikikoplus programs like synergy dont work (but ok that's expected I guess)06:36
duflurobert_ancell: The hang bug is incomplete. I haven't stress-tested MM recently to retry06:36
hikikoduflu, and there's no way I use X without mir for the 2nd wm so that I can debug more easily the xmir? (eg attach a gdb etc)06:36
dufluhikiko: I don't think you can right now due to the input focus problems. RAOF will have it fixed soon. Meanwhile you probably need a second machine06:37
hikikoouch :)06:38
RAOFhikiko: Yeah, you can; but until https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1192843 is fixed all keyboard input will always go to XMir.06:38
ubot5Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress]06:38
dufluAlternatively, go old-school and move your desktop to a text VT :/06:38
tvoss_duflu, not sure what you mean?06:38
duflutvoss_: You were going to benchmark OpenArena with the Mir-native-SDL ?06:38
dufluOr something06:38
hikikoand could you guys suggest me a bug that is important to fix and none of you is working on it atm?06:38
dufluhikiko: I think generally anything Critical in the mir or xmir projects06:39
hikikobecause most of our critical bugs are either GPU specific (need ATI for example) or assigned from what I see06:39
dufluHmm, maybe we should unassign those not in progress06:39
hikikokevin suggested one that is a test failure (but it's a bug that only appears some times) that ^ you said is incomplete06:40
hikiko3 others are ATI Specific06:40
dufluhikiko: Bug 1206633 is a killer. And close to code you have seen recently...06:41
ubot5bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,Triaged] https://launchpad.net/bugs/120663306:41
hikikocool :D06:41
dufluThough that might just be upstart scripting. I guess I should test06:41
hikikoI'll pick this one then!!06:41
tvoss_duflu, yup, got the numbers, need to post-process them06:42
dufluhikiko: It might not be a bug. Maybe just our upstart scripts need better dependency rules06:42
hikikoyes I saw your comment06:43
hikikoI'll give it a try though06:44
dufluhikiko: I also recall that exception wasn't clear which function it came from. Can also happen with errno==0. So maybe you should make the exception clearer first... and mention which function failed06:46
hikikoyes, I did that when I was testing for the nested mir: it was permission denied not success06:47
hikikoand my guess is06:47
dufluhikiko: I mean, it would be good to propose a branch with better exception details first06:48
hikikothat the problem is that we have that test (what interface version is used?) before we set the drm master06:48
hikikooh :)06:48
hikikotrue!06:48
hikikowill do!06:48
hikikook, cool!I'll start with this bug :D thank you duflu!06:48
hikikofinal question: for as long as I only have my laptop for development06:52
hikikois there any way to disable and enable xmir?06:52
hikiko+if I start xserver without -mir and then I start my compiled version of xmir (the branch I work) will I get a crash?06:53
dufluhikiko: Yes, comment out type=unity from /etc/lightdm/lightdm.conf.d/*06:53
hikikoduflu, if I do so, and compile/start xmir I wont have any issues isnt it?06:54
hikikoor I have to remember to enable it before I test?06:55
hikiko(enable the system's xmir)06:55
robert_ancellbye all06:55
dufluhikiko: That only affects the default system logon. You can still run any server manually06:55
dufluBye robert_ancell06:55
hikikocool that was my guess :)06:55
hikikothanks duflu :)06:56
dholbachgood morning07:00
dufluMorning dholbach07:14
dholbachhi duflu07:15
dufluRAOF: All root fragments share the same Drawable right?07:52
RAOFCorrect.07:52
RAOFThey're all associated with the root window, as seen by pScreen->root07:53
dufluRAOF: Looks like we don't filter damage reports to check if they overlap the fragment in question. Any damage effectively damages all fragments07:54
RAOFThis is correct. *but* we take the intersection of the damage with the fragment's region before updating the damage regions.07:54
dufluRAOF: Still, that explains why on the Mir side I was seeing all outputs redraw even when only one should... ?07:55
RAOFNo, I don't think so?07:55
dufluOK, forget I said that. It's tangental07:55
RAOFWe *should* only be calling the driver's copyproc when xmir_window_is_dirty() returns true, which is iff RegionNotEmpty(xmir_window_get_dirty(xmir_win)) returns true.07:56
hikikoduflu, still here?08:25
dufluhikiko: Yes, but about to vanish for a brief while... ?08:26
hikiko:)08:26
hikikoI have a question but ok, I'll find out! good evening :)08:27
dufluhikiko: I'll be back soon. What is the Q?08:27
hikikowell, I wonder how and when xmir starts working with the xserver (because I remember that when I was implementing the mir display for X I had to do a trick to tell the xserver not to handle the drm device that mir is using and I want to see if this is necessary in xmir as well)08:30
hikikoit might be related to the 1206633 bug08:30
hikikobug #12063308:31
ubot5bug 120633 in telepathy-mission-control (Ubuntu) "Sync telepathy-mission-control 4.26-1 from debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/12063308:31
hikikosorry08:31
hikikobug #120663308:31
ubot5bug 1206633 in Mir "Mir/unity-system-compositor fails to start: Error opening DRM device" [Critical,In progress] https://launchpad.net/bugs/120663308:31
dufluhikiko: I don't think there would be any remaining races for DRM devices in the X server. Because it is single threaded. More likely other processes racing, like maybe plymouth has not finished deactivating yet08:58
hikikothe only reason I suspect xserver is because I get the bug when I start a 2nd instance of lightdm which starts a second instance of xserver09:03
hikikowhen it's only lightdm and plymouth I dont get the freeze09:04
hikikobut ok, I'll test a few other things first :)09:04
dufluhikiko: Try adding a sleep and retry. That will give you an idea of whether the race just lasts a split second09:05
hikikoI will :)09:07
dufluRAOF: That's fun. Each frame XMir is looping through my *unused* outputs as well as used09:52
duflu... or something.... because I have 6 XMir wins to loop through09:52
dufluHmm, sometimes 8. This is quite strange09:56
davmor2hey guys, I think I found an odd issue, if you hit the power button at any time in saucy the machine shutsdown with no prompts, this includes if the machine is in lock/sleep mode,  meaning someone could leave their machine and it sleeps and locks and someone else hit the power button, all their work is then lost10:17
tvoss_davmor2, did you try it without Mir?10:18
tvoss_davmor2, that is, without unity-system-compositor?10:18
davmor2tvoss_: nope but I can10:19
dufludavmor2: Yeah I thought it was a new feature. I like it. Has nothing to do with Mir though10:19
davmor2duflu: I'd of said it was a critical regression it should switch off in locked mode it should just popup the user password dialogue box10:20
davmor2shouldn't switch off even10:20
dufludavmor2: I suggest you raise it in #ubuntu-desktop. It's really unrelated to this channel10:21
davmor2duflu: will do thanks10:22
dufludavmor2: Though it's not a security issue. Anyone with physical access to the power button always has the ability to kill a machine. There's no change there10:22
davmor2tvoss_: so yeah happens with with mir removed too10:23
tvoss_davmor2, then it's not a an xmir issue10:23
davmor2duflu: indeed that is the case for a hard press but if someone though the machine was hibernating and taps the power button to wake it like they do on windows instant shutdown may not be the desired result :)10:25
=== hikiko is now known as hikiko|lunch
dufluI like it. I always hated having to click on a dialog after I've already pressed the power button.10:26
dufluAnd it's better than Windows' annoying behaviour of always suspending, IMHO10:27
davmor2duflu: I have no issue with it in an unlocked system, but if I lock my system I'd rather be forced to open the system and ensure there is nothing unsaved before my system shutsdown on me :)10:28
dufludavmor2: Fair point. And Ubuntu design often makes contentious decisions. You should probably start by raising it in #ubuntu-desktop10:29
davmor2duflu: I am now :)10:30
=== dholbach_ is now known as dholbach
=== hikiko|lunch is now known as hikiko
MirvI filed bug #1220652 now for my problem. the attachments may not be very useful since I'm running normal X again, but just in case someone would have an force-rebootable desktop at some point and could try to reproduce my problem11:40
ubot5bug 1220652 in unity-system-compositor (Ubuntu) "Input devices gone in xmir after forcefully killing unity-system-compositor" [Undecided,New] https://launchpad.net/bugs/122065211:40
Mirvand input devices disappearing might be a bit weird anyhow, not shown in the normal logs.11:41
Mirvoh, added the tidbit that writing in VT1 also has the text in VT7, but in lightdm itself I can't type or move mouse11:42
tvoss_Mirv, what would be the expected behavior from your pov when forcefully killing usc?11:44
Mirvtvoss_: to that matter, it restarting itself gracefully like unity does11:47
tvoss_Mirv, that would be an upstart task, wouldn't it?11:48
Mirvtvoss_: yes, I think11:48
tvoss_Mirv, might be good to mention that in the bug report, too11:49
Mirvadded ", even after reboot" to the bug title to make it more clear that the killing is not the main issue11:49
Mirvbehavior in kill situation might be worth feature request in another bug, but that bug's intend is that I can't use xmir at the moment anymore, for some mysterious reason X11:49
MirvI'll file another bug for the request to gracefully restart itself11:50
Mirvand that is bug #122065611:51
ubot5bug 1220656 in unity-system-compositor (Ubuntu) "Feature request: gracefully restart after being killed (or crashed)" [Undecided,New] https://launchpad.net/bugs/122065611:51
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
tkamppeterI have serious multi-screen problems with the XMIR as of saucy release (not -proposed) should I report a bug or are there already fixes in the queue for which I should wait?13:06
kgunntkamppeter: one minute while i dig13:08
kgunnwe've tagged multimonitor here https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor13:08
kgunncurious are you on intel? or ati/nvidia?13:08
tkamppeterkgunn, I am on Intel, Lenovo Thinkpad Twist with Core i& with its built-in GPU.13:09
kgunntkamppeter: yeah, i'd skim thru the multimonitor tagged bugs...if you don't find a match/similar bug...please file13:11
tkamppeterkgunn, it seems to be bug 1216472, workaround (1) of this bug solves the problem.13:27
ubot5bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/121647213:27
kgunncool13:27
tkamppeterkgunn, I have marked the "Me too" now and subscribed to the bug.13:28
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
hikikobye!15:09
kdubwe need a way to change the client-side connection configuration in integration/acceptance tests15:59
alan_gkdub: which parts of the configuration can't you change?16:01
kdubif we use mir_connect, we can't put in a stub client-side graphics platform16:02
kdubwas thinking of changing it a bit to use some test connection functions16:02
kdubbut its just nice that the client's exec() in our test framework just uses our public api16:03
alan_gkdub: yes, we should have made the client API mockable16:04
kdubalan_g, would you be opposed to having integration and acceptance tests connect with something like mtd::mir_connect()?16:07
kdub(which allows us to put different client connection configurations in, depending on whether we want real graphics or not)16:07
alan_gkdub: If I were not starting from here I'd add a level of indirection so that all the API calls could be intercepted by test doubles.16:10
kdubwith 'here' being 'lots of acceptance/integration tests already written' ?16:11
alan_g"here" being introducing function pointers breaking the ABI16:12
kdubah, understood16:12
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
alan_gkdub: I think the better way is for mir_connect() to call through a function pointer  that defaults to the current implementation, but can be replaced for a test.16:16
kdubyeah16:17
kdubor even, maybe put that function into mir_client_library_debug.h16:18
kdubprobably worth doing, two critical bugs about the tests have popped up related to this16:19
alan_gkdub: "that function" being the existing implementation and the function pointer?16:25
kdubwell, i'm currently thinking the path of least resistance will be a mtf::test_client_connect() function that returns a MirConnection*16:26
kdubas opposed to adding a mir_connect(<current args>, MirClientFnPtrStruct*)16:27
kdubno touching the API, just a small inconvenience for tests16:28
alan_gkdub: I was thinking of a global pointer variable, not an extra parameter16:29
alan_gmir_connect() calls through (*mir_connect_impl)() which defaults to mir_connect_default_impl()16:30
kduband that global pointer can be overwritten via a debug function?16:31
kdubrather, a function in mir_client_library_debug.h16:32
alan_gOr just declare it in mir_client_library_debug.h and allow it to be assigned to16:33
kdubyeah, i'll see which is nicer (i'll try to keep the struct containing the function pointers hidden)16:34
racarrMorning...!16:46
racarrZzzz. im not sure its worth it for me to go to the late night weekly16:47
alan_gAfternoon...!16:47
racarrbecause I try but this ends up happening every week16:47
racarrHey alan_g ! How have you been?16:48
alan_g;)16:48
alan_gracarr: I've been good.16:48
alan_gHow was your vacation?16:49
racarralan_g: It was great!16:52
racarrLeft a significant portion of my stress in the desert :)16:53
alan_gExcellent. (Now let's see if we can fix that...)16:53
alan_gracarr: kdub: I've left a couple of MPs for you to review.16:55
kdubwill look16:56
* alan_g sneaks off 3 minutes early to mother-in-law's birthday...16:56
=== alan_g is now known as alan_g|EOD
kdubfun gcc error: "The bug is not reproducible, so it is likely a hardware or OS problem."17:50
racarrkdub: Lol beautiful17:53
ricmmolli_: kgunn sorry guys chrome crashed19:59
robert_ancellracarr, "Renamed toggle_dpms to toggle_dpms_between_on_and_off" - love it :)21:11
racarrrobert_ancell: :D I felt pretty happy about that too21:31
racarrricmm: Can you tell me more about the screen blanking stuff in upowerd and the small hack you mentioned? I think our DPMS support API is pretty ready to land, so if the mechanism is simple21:43
racarrmaybe I can just do the android impl...like right now!21:43
kgunnrsalveti: ^21:50
rsalveticool21:51
kgunnrsalveti: also...did i see you mention it was easy to crash (or freeze) mir on N4 today ?21:52
rsalvetikgunn: yup21:52
rsalvetijust installed today's mir image, and could easily crash mir when opening the browse-app, getting back to the shell and then killing the app21:53
kgunnrsalveti: any particular sequence? ( ive been testing regularly....but admit, i hadn't updated today)21:53
kgunneeewww21:53
rsalvetilet me reboot and give it another try21:54
kgunnrsalveti: one more....what are "input_tests" ?21:54
kgunne.g. how to replicate what you see in terms of failed input handling21:54
rsalvetioh, it's just that currently powerd is listening for the input events directly21:54
rsalvetito support the power button21:55
rsalvetithat's not the desired way when mir is in place, but it was the way we did this with SF21:55
racarrHowshould powerd get the power button21:55
racarrwithout a window, it doesnt seem it should get it from mir21:55
rsalvetiwhat I tried to check is if we were able to get the input events via hal, which wasn't the case21:55
racarrso it needs to communicate with unity somehow21:55
rsalvetiseems Mir was getting all the events somehow21:56
rsalvetiwell, powerd is not the right one to handle the power button21:56
ricmmracarr: not really, just exploring a simple interface via the HAL21:56
ricmmracarr: I can take a look at it21:56
ricmmthe shell needs to implement policy, powerd execute it21:56
rsalvetias we discussed during that previous call, we need someone that is already handling the input events to handle that power button21:56
ricmmthats the decision we had made21:56
rsalvetiand communicate with the system to let it suspend/resume21:56
rsalvetiyeah21:56
ricmmor in this case, the other way around... powerd executes the policy by asking the shell (Mir) to blank the screen21:57
ricmmout via the android impl for DPMS, but all we really need is a screen on/off toggle21:57
ricmmno more21:57
racarrI don't understand where powerd helps us here, because21:57
ricmmrsalveti: do you know if a basic HAL interface for this?21:57
* ricmm looks21:57
rsalvetiright, but powerd is not the one listening for the power input events21:57
racarrthe shell, needs to make the policy decision (no one else should see all the input events)21:58
rsalvetiat least it shouldn't be21:58
racarrbut, then if the shell uses powerd for the mechanism21:58
racarrmir in turn needs to respond to the screen turning off (explicitly, or through error conditions I guess)21:58
ricmmpowerd will work the idle timeout21:58
racarri.e. stop the compositor, stop handing out buffers21:58
racarretc21:58
ricmmthe shell will work the power button and ask powerd if it should suspend21:58
racarrso why not just have mir turn off the screen21:58
racarrFor powerd to work the idle timeout21:58
kgunnracarr: i think they are saying the shell should own that policy21:59
racarrhow will that work? i.e. it sees the stream of all input events?21:59
racarrOr does unity send it an event like "idle"21:59
kgunnfor making decisions about whether or not to actually blank the screeen21:59
rsalvetiwho is handling all the input, mir, right?21:59
ricmmwant to jump in a hangout?21:59
racarrYes21:59
rsalvetione thing ins handling the power button input21:59
ricmmhttps://plus.google.com/hangouts/_/f4a766e9a7fc27ef894ab5ac8235856049fc75ab21:59
rsalvetithe other is the timeout21:59
racarrkgunn: I am interpreting the opposite XD22:00
racarrThanks :) will give screen blanking a shot in 10-15 min22:19
robert_ancellracarr, in src/server/shell/default_focus_mechanism.cpp, there is a reference held to the currently focussed surface that is never cleared until another surface has focus. Do you see any issues there if the surface is destroyed?23:01
racarrrobert_ancell: Yes. That's the second part of the stress test race23:02
racarrrobert_ancell: I tried to fix it with session-transactions but need to come up with another solution I guess23:02
robert_ancellracarr, do you have a branch that fixes that specific part of the code? Because I'm modifying that code to support dropping focus on vt switch23:02
robert_ancellah23:02
racarrI think it may be resolvable with a weak reference23:02
racarrplus the appropriate logic when lock fails23:03
racarror the other idea I had was a different approach to session transactions hwere consumers of the surfacers in the shell store23:03
racarrmf::SurfaceId and there is an api like23:03
racarrsession->with_surface_do(SurfaceId, [&](msh::Surface& surface) { stuff })23:03
racarrI think it is the cause of some of the phone crashes gerry is seeing so I am taking it on after DPMS23:04
racarrScreen blanking is blocking mir on phone though, so I am taking a minor diversion from GBM DPMS to hopefully quite quickly implement android screen blanking XD23:04
racarrrobert_ancell: the thing is the surface will still be destroyed or whatever but exceptions may throw when you try to use it because the underlying surface is gone23:05
robert_ancellright23:05
racarrthere is another race in the same section of code23:05
racarr    auto surface = focus_session->default_surface();23:05
robert_ancellracarr, is there an easy way to detect that without just ignoring exceptions when accessing it?23:05
racarrThen a few lines later:         surface->raise(surface_controller);23:06
racarrbut the underlying surface could be destroyed23:06
racarrrobert_ancell: Not really because without some sort of lock it can always happen inbetween23:06
racarryour detection and operations23:06
racarrso you need some way to do things atomically.23:07
racarrI guess a weak_ptr is not enough.23:07
racarrI like with_surface_do sort of. but im not sure it will land23:07
racarrlet me figure out why session-transactions was rejected I dont remember23:07
racarrok the recursive mutex.23:08
racarrhmm23:09
racarrthe problem is, the idea is with_surface_do or do_transaction or whatever is that it holds a lock on the session that prevents destroy_surface, etc from running during the body of your function23:10
racarrbut then certainly the body of the function should be able to call these methods23:10
racarrso you need a recursive mutex.23:10
racarrrobert_ancell: Ok I have an idea23:13
racarrthe focus mechanism needs to track the last surface, so it can unfocus it when a new surface takes focus23:14
racarrso...um...23:14
racarranother way to do that? XD not sure what the pattern is23:14
racarrerr, nvm I thought myself in a circle23:16
racarrI was thinking about, passing out token objects to the surfaces23:17
racarrthat know how to generate unfocus events when they are destroyed23:17
racarrbut it doesnt seem to make sense23:17
racarrMaybe the transaction API, but just don't use a recursive mutex23:21
racarrand make it clear that calling session functions in the body of this is a deadlock23:21
racarrwith some API like23:21
racarrsession->do_with_surface_while_freezing_requests(mf::SurfaceId, std::function)...23:22
robert_ancellracarr, but what do we do when the last surface is removed and then we try and access it afterwards?23:23
racarrMm23:24
racarrOk maybe remove the SurfaceId from the API and the session tracks23:24
racarrits last focused surface (as the default_surface I guess)23:24
racarrand there is API like23:24
racarrsession->with_default_surface_do23:24
racarrstd::function23:24
racarrI need to run some errands. Back in ~1 hour23:29

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