[04:43] <RAOF> Bah!
[04:44] <RAOF> QT CREATOR!!!!!!!!!
[07:14] <anpok> alf_: do you have any thoughts regarding a new separate namespace for main loop, timer service..
[07:19] <RAOF> I don't think it's a terrible idea, but I'm not sure what it would be.
[07:19] <anpok> scheduler is a hot candidate.. like event_loop
[07:20] <RAOF> That's a pretty decent name.
[07:20] <alf_> anpok: mir::services? scheduler is not bad
[07:20] <anpok> RAOF: btw, regarding mesa - all issues so far were solved through pulling in further autotools related patches from master
[07:21] <RAOF> You autotools!
[07:21] <anpok> RAOF: what is currently in the archive is a non-functional gallium backend
[07:21] <RAOF> Ah.
[07:21] <RAOF> Heh.
[07:21] <anpok> RAOF: now it stumbles getting a good EGLConfig - i.e. surface attribute bit is wrong iirc
[07:22] <anpok> alf_: sounds good but, but what is not a service? (maybe I misnamed timer service?)
[07:22] <anpok> -but
[07:23] <alf_> anpok: fair point
[07:26] <anpok> RAOF: ah right, this one is really odd.. all config entities it checks have EGL_PBUFFER_BIT = 0x1 and one that is not listed in egl.h 0x10... so it is 0x11 while we want EGL_WINDOW_BIT = 0x4 to be set
[07:26] <RAOF> Hm. Incorrect shift?
[07:27] <anpok> I have not yet found the place where those config objects get assembled..
[07:28] <anpok> oh no it isi 0x8 + 0x1 actually
[07:28] <anpok> but that one is also not listed in egl.h
[07:28] <anpok> not as a surface type at least
[07:30] <anpok> alf_: i would like to introduce an interface like main loop that does not say "i am a single instance" - maybe something like EventLoop or Scheduler .. dunno .. which provides the FD/Timer/ActionQeueu (services :))..
[07:34] <alf_> anpok: Whether this is going to be useful depends on what needs our consumers have. For example at the moment we have a need for synchronized FD + Signal + ActionQueue (current MainLoop) and a Timer which doesn't need to be sync with them.
[07:35] <alf_> s/synchronized/serialized/
[07:35] <anpok> hm input sender needs fd + timer, none of them need to be serialized.. or in the main loop or ..
[07:36] <alf_> anpok: I guess if two services don't need to be serialized between them, we might as well pass them as separate interfaces?
[07:36] <anpok> yes
[07:37] <anpok> oh .. sorry that was what I wanted to express
[07:37] <anpok> s/an interface/a class/
[07:38] <RAOF> The way AsioMainLoop provided both mir::MainLoop and mir::Timer? :)
[07:38] <anpok> yes..
[07:39] <anpok> so that we can decide within server configuration which thread handles which type of events for which part of the mir functionality
[07:39] <alf_> anpok: RAOF: Didn't we split them apart to make things simpler? :)
[07:39] <anpok> yeah lets revert
[07:41] <alf_> anpok: hmm, if we really need this can we somehow use composition to provide the functionality and keep the eveng logic in separate classes?
[07:42] <alf_> anpok: instead of going back to the the loop super file?
[07:42] <anpok> yes.. that should be a driving goal
[07:42] <anpok> also getting rid of the unpredictable parts of asio
[07:43] <anpok> I wont be working on that this week or so..
[07:43] <anpok> Just thought about it again, as I am updateing the MPs again
[08:05] <RAOF> Man I wish gdb worked.
[08:23] <alan_g> RAOF: ? It has been working for me for at least a decade
[09:03] <RAOF> alan_g: Tried it on mir_unit_tests recently? It segfaults while trying to load the debugging symbols.
[09:04] <alan_g> RAOF: yes, I've been using it to track down weird behaviour in trust-session APIs
[11:10] <alan_g> alf_: thanks for the clue - that's fixed now and I don't have to worry about a mystery CI failure. [@https://code.launchpad.net/~alan-griffiths/mir/rework-test_client_library_old.cpp/+merge/222018/comments/533359]
[11:11] <alf_> alan_g: great, glad I could help
[11:58] <anpok> alan_g: i just realized that you suggested scheduling, while I propose scheduler instead..
[11:58] <alan_g> anpok: scheduler is likely better.
[11:59] <anpok> ... ok then I will rebase the input sender on that..
[12:07] <anpok> hm I should move TimerService too
[12:59] <anpok> alf_: I am inclined to rename mir::graphics::EventHandlerRegistrar to scheduler::FDHandlerRegistrar
[13:00] <anpok> because in input::InputSender I only use that part of the main loop interface
[14:00] <anpok> alan_g: alf_: kdub_: is the order in which parts of the DisplayServer are started and stopped relevant?
[14:00] <anpok> I see we do have test cases that ensure a specific order..
[14:01] <alan_g> anpok: yes (but I can't remember details)
[14:01] <alf_> anpok: yes
[14:01] <anpok> I think about your complaint about the name TimerService..
[14:03] <alf_> anpok: TimerServiceManagerer :P
[14:03] <anpok> hehe
[14:04] <anpok> that part of the interface is only there to start&stop it.. so maybe we could inverse it.. and make it an observer of the server state, and react by starting and stopping the thread
[14:04] <anpok> or provide a StartStoppable (suggestions welcome) interface
[14:05] <anpok> that could be driven by DisplayServer
[14:05] <anpok> but that means the we strictly follow insertion order on start and backwards on stop..
[14:05] <anpok> s/the we/that we have to/
[14:07] <anpok> or on third thought..:
[14:07] <alf_> anpok: there is also the pause/resume case which has some special needs
[14:07] <anpok> class AlarmLoop : public AlarmService
[14:38] <AlbertA> kdub_: for your alpha question yesterday...
[14:38] <AlbertA> kdub_: the issue with the alpha originally was yes, the alpha channel in nested was not initialized
[14:39] <AlbertA> kdub_: so then we initialized it to opaque
[14:39] <AlbertA> kdub_: that doesn't work for the split greeter work as it relies on being able to show through multiple nested sessions
[14:40] <AlbertA> kdub_: so then I modified it so that a nested transparent display buffer would get its alpha channel written
[14:41] <AlbertA> kdub_: and the last change was to make it actually write correct alpha
[14:41] <AlbertA> kdub_: to avoid alpha^2'ish effects
[18:52] <kdub_> sigh, why did we lose the rich pixel format type
[19:08] <anpok> kdub_: from the conversations I heard it was just side effect of unification of two types..
[19:13] <kdub_> heh, i'd say the type was just c-ified :)
[19:24] <anpok> code is patient
[19:24] <anpok> or version control systems at least
[19:25] <anpok> kdub_: maybe a good time to get that mp through :)
[19:27] <kdub_> yeah, seems like a big chunk to improve given how pervasive the type is though
[19:28] <kdub_> other fish to fry
[19:30] <anpok> hm are there affordable displays to test depp color pixel formats
[19:31] <anpok> i only know that mine sucks even at displaying 8 bit per channel
[20:34] <anpok> hi racarr_
[20:57] <racarr_> anpok: hi. What's up?
[20:58] <racarr_> seems like there was netsplit or something.
[20:58] <racarr_> did I miss something?!?!
[20:59] <anpok> nope
[21:00] <racarr_> haha
[21:00] <racarr_> I was just converting cursor test stuff to inprocess server test
[21:00] <racarr_> to find this intermittent failure
[21:00] <racarr_> and found that but still have the other half of the tests to convert now.
[21:00] <racarr_> then...I have to do the same thing for this enable usb touchscreen branch lol
[21:01] <racarr_> I feel good about getting more fake devices in fake event hub though
[21:01] <racarr_> I was thinking after that branch lands I will add a fake joystick.
[21:03] <racarr_> fake wacom style tablet, etc.
[22:11] <racarr_> hmm
[22:11] <racarr_> I have a weird throw in std::mutex::lock I dont understand
[22:12] <racarr_> Throws std::system_error when errors occur, including errors from the underlying operating system that would prevent lock from meeting its specifications. The mutex is not locked in the case of any exception being thrown
[22:12] <racarr_> like what!
[22:13] <racarr_> oh I understand
[22:13] <racarr_> lol
[22:13] <racarr_> good talk
[23:26] <kdub_> why do we have a Width /and/ a DeltaX
[23:32] <RAOF> anpok: The Dell UltraSharp line does (reasonably) affordable 10bpp panels; even the crappier ones are full 8bit. :)