[10:55:00] *** apw (~apw@hellhawk.shadowen.org) has joined chat #plymouth. [10:55:10] * apw waves [10:55:56] i am wondering at plymouths relationship with the VT during boot, specifically if it is aware of and handles resizes triggered by a framebuffer switch [10:56:51] * apw hears rumours that halfline is the man to ask [10:58:58] apw: we listen for SIGWINCH but the splash screens don't do anything response (like resize themselves) [10:59:17] apw: so i'd say it handles it but in a half-assed way [10:59:26] would we redraw at least ? [11:00:35] not really. i mean the splashes are redrawing on their own [11:00:44] as they need it for their own purposes [11:01:06] basically more work would be needed for this to work well [11:01:23] vt_event_post(VT_EVENT_RESIZE, vc->vc_num, vc->vc_num); [11:01:43] halfline, it actually looks like we'd get a VT_EVENT_RESIZE down the vt control pipe [11:01:57] yea there are a couple notifications i think [11:02:03] (rather than a SIGWINCH) [11:02:09] shouldn't get both i think [11:02:15] *should [11:02:22] so i guess we could generically 'stop_animation' and then 'start_animation' perhaps [11:03:18] well lets take a step back [11:03:33] why is the framebuffer changing dimensions during boot up? [11:04:04] halfline, KMS it switching mode [11:04:06] for boot up to look really slick you don't want to be switching modes more than once [11:04:30] right, that is the one mode switch but its occuring now after plymouth has started .... at least i believe so [11:04:46] so most distros call plymouth show-splash only after kms is loaded [11:05:11] if kms isn't available [11:05:19] then plymouth show-splash will show a fallback text mode splash [11:05:35] I think that's exactly what we do now [11:05:53] i.e. call show-splash after kms is loaded [11:06:09] oh [11:06:23] and i am assuming its plymouth that is switching us over to graphics [11:06:32] nope [11:06:35] its may be very nearly coincident though [11:06:38] plymouth just rides the wave of whats available [11:06:51] halfline, sorry i am confusing you i suspect [11:06:59] i don't mean it triggers the KMS switch to higher res [11:07:15] oh you mean KD_GRAPHICS mode ? [11:07:20] it's true that plymouth switches to KD_GRAPHICS, if that's what you meant [11:07:28] i mean that the VT has moved over to VT_GRAPHICS mode, so that the underlying .... [11:07:31] yeah ok [11:07:51] yea plymouth does that if kms is available [11:07:55] (or legacy /dev/fb) [11:08:16] so in this test kernel i have here (he says pointing) we are up with fbcon down on the VT, then KMS comes along and shoves it aside [11:08:27] unstacking fbcon and stacking on drm_somethingsomthing [11:08:49] and we get two resizes from 128x37 or something to 80x25 as the unstack occurs and back as drm goes down [11:09:01] but in both cases we are already in graphics mode on the VT [11:09:19] so plymouth must have hit the VT before KMS did its whole thing [11:10:20] so you go from 128x37 to 80x25 back up to more than 80x25 ? [11:10:26] halfline, i guess i am wondering how we can make plymouth start more sympathetic to there being something pretty in the framebuffer already [11:10:53] the VT sees those size transitions, now i suspect there is not an associated actual size change of course [11:11:14] as there was likely only a KMS change from in my case 1024x768 to 1024x800 [11:11:24] does that not knock the terminal out of _GRAPHICS mode? [11:11:37] so normally the progression is [11:11:39] text mode [11:11:42] graphics mode [11:11:52] the kernel starts in text mode [11:12:06] doesn't seem to have any effect, as the console is in _GRAPHICS mode so it resises the internal representation of the text and then does nothing with it [11:12:14] are you saying in your case, you're in a vesa mode or some such and kms happens from there? [11:12:21] halfline, right it does indeed [11:12:52] yep cjwatson has gotten some grub2 patches which init grub into a vesa mode [11:13:16] and then boot the kernel without changing it, i am trying to work out how to not clear that out before plymouth can take over [11:13:25] oh okay [11:13:38] so you've patched the "force text mode" out of the kernel [11:13:58] well the kernel doesn't actually change the mode at all until kms starts [11:14:20] all i am really doing is preventing the text mode VT from actually writing over the display unnecessarily [11:14:35] are you sure about that? i thought it did, but could be wrong i guess [11:14:47] i have some notion of mjg59 looking into it and saying it did [11:14:55] right now i have some sample patches which make the VT "transparent" so that if we write any text onto the VT_TEXT mode it will appear [11:15:18] s/will/wont/ ? [11:15:23] there is no mode change in the kernel. we assume the mode is set on the console on boot [11:15:37] the patches make 'spaces' a noop if that makes sense [11:15:48] so if we refresh the VT and its all spaces nothing gets changes [11:16:05] if it has some text on it then the letters are formed, but the rest of the display is left alone [11:16:20] effectivly making spaces 'transparent' to whatever grub left on the display [11:16:30] oh, you don't clear the transparent areas? [11:16:37] so you get text on top of the graphics that was there before? [11:16:45] anyway going back to plymouth [11:16:57] right ... now in theory we don't print anything so it looks nice, if we do need to we still can talk to the user [11:17:12] gotcha [11:17:17] like if we panic early for instance [11:17:40] (all of this is experimental and subject to radical rethink, based on what you say here :) ) [11:18:35] so the issue is [11:19:14] hmm [11:19:48] so i don't think we want plymouth started until kms is loaded [11:19:50] i think most of the issue is i don't really know how the plymouth startup and transition to X works [11:20:00] you probably don't want plymouth to suddenly redraw and change aspect ratios [11:20:18] halfline, yeah i wonder why that is occuring in fact [11:20:37] right, so i think if you nail down why that's occuring then your issue will become moot [11:21:17] i wrote a blog post a long time ago on how the transition to X works [11:21:22] tseliot, how does handoff to X work [11:21:31] as it doesn't seem to be workng right to my eye [11:21:33] it's still mostly relevant although things are a little different now from changes Keybuk did [11:21:53] sounds useful [11:22:03] apw: http://blogs.gnome.org/halfline/2009/11/28/plymouth-%e2%9f%b6-x-transition/ [11:22:30] i actually have to run. i have a deadline in 45 minutes [11:22:45] halfline, thanks for your input :) much appreciated [11:22:46] halfline: are they? I hadn't seen any recent changes to the transition stuff [11:22:55] Keybuk: nothing recent [11:22:58] oh, sorry, you mean the changes I did made things different [11:23:10] oh yea wasn't being clear [11:23:13] rather than now is different from when I made my changes [11:23:18] right [11:23:41] i'm saying the blog post is older than the work you did [11:23:53] Keybuk, hey ya ... [11:23:54] not that what I did is necessarily right, but it works :p [11:24:14] I have no idea [11:24:39] :) [11:25:33] well you can start plymouthd early, just don't show-splash until the display is set up [11:25:43] apw: when a graphics device shows up [11:25:51] err, actually what halfline said [11:25:55] we start *plymouthd* on startup [11:26:00] we show splash later when we have an fb0 or dri0 [11:26:33] isn't the actual mode switch async relative to the completion of the driver init? [11:27:02] this may be related to Colin's work to plumb an EFI or VESA framebuffer earlier? [11:27:06] and thus can't it happen much later [11:27:09] I have no idea [11:27:21] that sounds like the kind of kernel-side thing you should investigate after you've applied that readahead patch :p [11:27:25] it is related to that indeed, though i don't think he has made any changes [11:27:55] Keybuk, heh i am investigating it how :-p which is why i am here whining that i know nothing :) [11:28:00] now [11:28:30] Keybuk, are you suggesting that you've tested the readahead kernels and they work for you ? [11:28:36] yes, I sent you an e-mail about it [11:28:44] I've tested the same patch on -7.12 too [11:28:47] and I have a ureadahead package that uses the patch for awesomeness and fluffy bunnies [11:29:11] but, err OT [11:29:23] but going back to plymouth [11:29:44] plymouth just needs to be told when to show the splash [11:29:51] I don't think it, itself, gets any indication about mode changes [11:30:02] and we're just using an "add" on dri0 or fb0 to show the splash [11:30:16] so if things are more async there than before, that wouldn't work so well [11:30:16] yeah, but plymouth puts the VT into VT_GRAPHICS [11:30:37] then there's the whole framebuffer changing from linear to planar thing you have to worry about [11:31:01] honestly i'd try changing your udev rule or whatever to strip out the legacy fb0 handling and see if your bug goes away [11:31:35] make show-splash only happen in response to kms being available [11:31:43] and i see the drm framebuffer shoving the fbcon off and replacing it, and we get two resizes, both after plymout has put the VT into graphics mode [11:31:51] right that could well be not helping [11:31:56] i think you're getting a spurious even as a result of getting started in vesa mode [11:32:00] halfline, yeah perhaps i'll do that to see if that makes things look better [11:32:19] though we do tag the rule for fb0 to say "not the one you're looking for" [11:32:57] ah maybe something's going wrong in the tagging [11:33:00] though again, if a VESA or EFI framebuffer exists first as fb0, that would be tagged as primary [11:33:03] since it's done by driver [11:33:12] (and indeed, we *want* to put a framebuffer on there) [11:33:32] 1) if i wait till kms has done its mode switch before letting plymout appear will i be visually ok [11:34:03] and 2) how do we know one is coming so we can do this test intelligently [11:34:15] no idea [11:34:36] actually can we just 'show-splash' more than once? [11:35:02] you don't want to show-splash early [11:35:14] because then you're going to show a splash that's non native resolution [11:35:20] no not really, but how do i know that the fbcon isn't the one that i don't want [11:35:23] halfline: we do, for various reasons :-/ [11:35:40] hmm, actually, do we? [11:35:41] no, sorry [11:35:46] I remember how this was going to work [11:35:53] yeah grub was going to paint something that looked like the splash [11:35:58] so the show splash shouldn't be until kms is ready [11:35:58] ah sorry guys i really got run [11:36:04] halfline, thanks man [11:36:20] and plymouth --show-splash is getting called [11:36:31] because the "do not use fb0" test is done on the underlying driver [11:36:33] so can we tell we have such a thing coming and that the first fbcon is unintersting [11:36:37] (which is vesafb/efifb in this case) [11:36:48] I'm not sure we can tell [11:36:57] because until the driver is loaded, we don't know if we have such a device [11:37:16] so back to the old 'wait 5s and assume its ok' problem [11:37:58] which we have been trying to avoid [11:38:02] right, and this is why I came back to just have plymouth show the splash for each device, and tear down/reshow for each device change [11:38:22] ok ... and am i expecting that to work as is? or not? [11:38:39] i'd say it is not from my visual tests [11:38:54] probably not [11:39:03] as i see grub splash, then plymouth dots, then KMS switch, then black, then X fades in [11:39:43] how can i frig this udev rule to only fire on the drm versions, as a bodge to confirm whether if it was redrawing after the kms switch it would look right [11:39:44] ? [11:40:57] and where indeed is the stupid rule ... grrr [11:41:57] Keybuk, ^^ [11:42:44] /lib/udev/rules.d/78-graphics-card.rules [11:43:00] just remove the PRIMARY_DISPLAY_FOR_DEVICE tag for fb* [11:43:47] hrm, thats not obvious as in grepping for plymouth and splash doesn't find it :/ [11:46:20] Keybuk, ok that i think is looking pretty right [11:46:38] but we are saying that we really have an issue in working out whether we need to use fb0 or not [11:47:01] or plymouth has to redraw on switch and detect the switch ... did you have an idea how we might do that? [11:47:01] I think it thinks it needs to use fb0 in your case [11:47:07] because the fb0 driver is not one of the kms ones [11:47:36] why does it need to use fb0 ? [11:48:42] because some people don't have i915 [11:48:54] right ... see what you mean [11:49:21] so what if we made the fb rule trigger plymouth hide-splash, plymouth show-splash [11:49:48] then it would appear on fb0, if we get a switch we would hide and reshow it on the new one? [11:50:00] (maybe) [11:50:30] maybe [11:50:36] though it shouldn't be a hide/show like that [11:51:08] is plymouth connected to the VT message channel ? i assume it must be to handle switching to and from it via the keyboard right ? [11:51:35] what message channel? [11:51:39] this is Linux, not Mach [11:51:42] as the resize events triggered by the fbcon being removed and drm being put on the top is sent to the same place i think (if i understand this code) [11:52:24] when you put a VT into VT_GRAPHICS you have to take responsibility for vt switches being requested right? you have to say yes i am off the display and redraw when its given back [11:52:57] that occurs somewhere ...signals whatever, you are told and must respond with ioctls right ? [11:53:11] right [11:53:31] that's VT_PROCESS [11:53:33] you get a VT_RESIZE via the same mechanism [11:53:45] if i am understanding things right [11:54:21] plymouth doesn't handle that [11:54:38] (and which signal would it use? it's already used up USR1 and USR2 for release & acquire) [11:54:57] there are plenty of other signals [11:55:07] if it is indeed requestable as a signal [11:55:12] SIGWINCH might be a good one [11:55:29] VT_SETMODE doesn't have an argument for a resize signal [11:55:33] (see man console_ioctl) [11:56:39] hrm [12:00:22] Keybuk, you can wait for it though [12:00:32] VT_WAITEVENT: [12:00:51] which is pittifuly not documented [12:01:22] so you can wait for a resize, and then do something to get the size or something ... bah [12:01:50] Keybuk, but i guess that doesn't matter as actually we get a udev event and we should be able to handle that no ? [12:02:10] from outside plymouth [12:12:10] we don't get a udev event for resizes that I know of [13:41:42] apw, Keybuk: inside the modinfo of the drivers there's a list of pci ids [13:42:05] you can just check those pci ids against the devices on the system [13:42:16] and if there's a match, ignore the fb0 udev event [13:42:17] Keybuk, no i meant we would get a second udev framebuffer appear [13:42:37] one for fb0 and one for drmfb0 or whatever its called [13:42:48] so if we decorate every one which fires we are golden [13:43:05] right the fact that the display is resizing isn't the relevant issue here [13:43:09] that's just a side effect [13:43:25] in fact it wouldn't resize at all if you had a 1024x768 monitor hooked up or whatever [13:44:01] so it's the wrong event to try to tryap [13:44:02] *trap [13:44:42] note if you change the plymouth show-splash in your udev rule to plymouth hide-splash; plymouth show-splash it may "work" but it's going to blink at a minimum [13:44:46] so i don't think that's what you want either [13:45:52] i really think the right course of action here is to filter out the fb0 even when you know you're going to get modesetting [13:45:58] *event [13:49:39] halfline, and isn't that the tricky bit knowing when you might get mode setting, especially as the user can override it [13:50:10] well i think checking pci ids should work okay [13:50:28] you might have to also check for nomodeset explicitly i guess which is a little icky [13:50:49] but it definitely seems right to avoid using the low fidelity interface entirely [13:51:49] udev might have an event for "i'm done processing the graphics subsystem" who knows [13:52:00] if so you could defer calling show splash until that event [13:54:46] in fact there probably is [13:54:50] i'd ask on #udev [13:55:17] or read up on udev more [13:58:34] oh rereading scrollback i just want to say that the mode is set synchronously upon loading the drm driver [13:58:47] it's not like "load early, mode comes a second later" [14:24:13] halfline, on the flash thing, i was proposing we paint the splash, as long as its the same it should remain no? [14:24:26] for the case where the resolution does not change [14:24:37] well the resolution will change in most cases [14:25:09] i guess you could do plymouth quit --retain-splash and then restart plymouth... [14:25:25] or hack up plymouth to have plymouth hide-splash --actually-please-dont [14:26:16] i guess plymouth could watch for the devices to come and go [14:26:22] and automatically use all devices [14:26:37] even though only one is scanning out at the given moment [14:27:07] anyway, it's doable, just a bunch more work than the alterantive [14:28:20] halfline, yeah needs some thought... thanks for all your input and background helps a lot [14:28:48] *** [ JUMP ] No window in FreeNode named #gdm. [14:30:00] sure [14:30:58] i'll just reiterate i think the best approach is to change your udev rule to fire when all the devices are registered instead of when any of the devices are registered [14:31:03] assuming there's an event for it ... [16:04:28] halfline, not sure there is any way to really know 'all of them have fired' as we don't know how many there are ... but there must be some way round this [16:12:27] apw: i mean the kernel goes through a probes devices [16:12:31] at some point it finishes [16:12:47] presuambly there is an event that gets fired when that probing is done [16:12:51] *presumably [16:13:09] so you should hook into that event instead of the event you're hooking into now [16:13:43] halfline, that is possible, cirtainly possible that udev cold-plug has an end event [16:14:07] right [16:14:15] there may be an even more specific event [16:14:25] not sure [16:15:33] basically at some point the kernel knows it's not going to be registering anymore fb devices [16:15:39] you need to hook into that [16:17:38] you could hook into both events i suppose [16:18:01] call plymouth --show-splash in the modesetting case as soon as it becomes available [16:18:29] but don't call it in the non drm modesetting case [16:18:38] and always call it after cold-plug [16:18:57] so the typical drm modesetting case isn't penalized waiting [16:19:19] yeah [16:19:46] i'll have keybuk in my clutches next week so i expect we'll do some work on it then