May 09 15:12:52 -->	kemurphy (~kemurphy@GHC19.GHC.ANDREW.CMU.EDU) has joined #plymouth
May 09 15:16:17 <kemurphy>	halfline: i'm just about done with the udev patch, but i've hit a snag
May 09 15:16:41 <halfline>	oh yea?
May 09 15:17:50 <kemurphy>	yeah, if i tell udev to actually scan for graphics devices and add the pixel displays before the event loop runs, then the event loop gets a SIGPIPE on it's second event
May 09 15:17:57 <kemurphy>	which seems really, really strange to me
May 09 15:18:34 <kemurphy>	(like, i'll call plymouth hide-splash, then plymouth show-splash, and the show-splash will hang, and i'll have to ctrl-c it and do it again, which works fine)
May 09 15:18:53 <kemurphy>	(but it's consistently the second event)
May 09 15:19:26 <kemurphy>	if i defer the scanning for devices until show-splash is called, the issue goes away
May 09 15:19:56 <kemurphy>	on a semi related note, why do the displays and keyboard get unloaded/freed and reallocated/reloaded for each hide-splash and show-splash, respectively?
May 09 15:20:11 <kemurphy>	i feel like it would be simpler if we just left them loaded when they were found
May 09 15:20:21 <halfline>	SIGPIPE means the fd you're writing to got closed
May 09 15:20:39 <kemurphy>	and rely on udev events to remove and add displays as needed
May 09 15:20:53 <kemurphy>	right, i'm just wondering why the fd closes prematurely
May 09 15:20:56 <halfline>	so first thing to figure out is which fd is getting written to
May 09 15:21:10 <kemurphy>	it's the boot server fd
May 09 15:22:02 <kemurphy>	or, wait, maybe not
May 09 15:22:34 <kemurphy>	maybe plymouthd is sending a reply to the udev fd by mistake... i'll look into it a little later
May 09 15:23:00 <halfline>	okay
May 09 15:23:12 <halfline>	re keyboard/displays
May 09 15:23:26 <halfline>	the main point is to make sure the tty is no longer being used by plymouth
May 09 15:23:48 <halfline>	if someone does hide-splash then plymouth shouldn't be watching the tty anymore
May 09 15:24:19 <halfline>	it very well could be we coudl get away with keeping them around, as long we make sure the fds are closed
May 09 15:24:34 <kemurphy>	okay, i see. is it only necessary to unload the pixel displays for that or does it have to be the whole renderer itself, in the current setup
May 09 15:25:20 <halfline>	the renderer does
May 09 15:25:30 <halfline>	watch_fd (...terminal_fd...)
May 09 15:25:37 <halfline>	inside open_input_source
May 09 15:25:47 <halfline>	so if you wanted to keep the renderer around
May 09 15:25:53 <halfline>	you sould have to close_input_source
May 09 15:26:01 <kemurphy>	ah, i see. would you accept a patch that closed fds and didn't bother freeing/reallocing the various resources?
May 09 15:26:09 <halfline>	sure
May 09 15:26:12 <kemurphy>	(independent of udev, i could split it out)
May 09 15:26:31 <halfline>	it's probably the way it is now, just because it was more convenient to write 
May 09 15:26:44 <halfline>	yea, i would appreciate it split out
May 09 15:26:58 <kemurphy>	yeah, i figured something like that was the case
May 09 15:27:19 <kemurphy>	alrighty then, i'll get that working in the next couple days and get back to you
May 09 15:27:22 <halfline>	changing things like that always has the potential risk of introducing regressions, so having it as a separate commit that can be easily bisected is always good
May 09 15:27:35 <kemurphy>	yeah, i figured
May 09 15:27:42 <halfline>	sounds good
May 09 15:27:43 <kemurphy>	separate commits for separate functionality etc
May 09 15:27:57 <halfline>	thanks for the help btw
May 09 15:28:15 <kemurphy>	sure thing, it's a fun project actually
May 09 15:28:44 <kemurphy>	i've had my eye on plymouth for a while and decided i was probably ready to dive in, so i think this was a good way to start
May 09 15:29:54 <kemurphy>	oh, also, i'm about to fire a patch to the mailing list that fixes a tiny bug in the drm renderer, if you wanna be on the lookout for that
May 09 15:30:08 <kemurphy>	it's only a few lines, shouldn't be a huge deal
May 09 15:30:21 <halfline>	okay i'll watch for it
May 09 15:30:27 <halfline>	someone else sent a patch earlier too
May 09 15:30:46 <kemurphy>	oh, let me see if it fixes the same thing
May 09 15:30:52 <halfline>	no
May 09 15:30:56 <halfline>	wasn't a drm patch
May 09 15:31:00 <halfline>	i think it was a docs patch
May 09 15:31:02 <kemurphy>	oh gotcha
May 09 15:31:24 <halfline>	just saying, when i get some cycles i've got two in the queue to review :-)
May 09 15:31:48 <halfline>	will try to look them over tonight after work
May 09 15:31:55 <kemurphy>	oh, i see, no worries :)
May 09 15:44:46 <--	kemurphy has quit (Quit: Leaving)