[09:48:05] ugh, lid sense. [09:48:23] i can not tell you how antipathic i am about lid sense. [09:50:15] mcepl: 595644 is a server bug. i guess. [09:50:19] we treated it as such in el6 anyway [09:50:35] g-s-d's probably a better place [09:50:54] mcepl: I'd assign it to desktop [09:51:00] It's a policy decision [09:51:06] desktop? which component? [09:51:15] Whichever one gnome-settings-daemon is in [09:51:21] mcepl: and yeah, when in doubt blame compiz [09:51:29] done [10:00:52] mjg59: how is that a policy decision? [10:01:11] halfline: Lid state can't be trusted, so you need to make a decision based on multiple factors [10:01:37] from a highlevel point of view, though, there's only one right answer [10:01:51] having to perform heuristics does not mean it's policy [10:02:02] policy means there are multiple right outcomes [10:02:05] halfline: Well, there's one right answer *if* the information can be trusted [10:02:24] If my laptop always reports the lid as closed then the right answer is different [10:03:22] federico was supposed to be looking at this at some point [10:03:22] no, not really. if youre laptop always reports the lid as closed, then the driver should ignore lid state and treat it as always open [10:03:34] halfline: The driver has no way of knowing that this is the case [10:03:57] it's a hardware quirk, yes? [10:04:18] It's a hardware quirk that seems to affect ~10% of machines, and gets fixed and broken in bios updates [10:04:21] so you say "this broken ass dell model gets the treatment" [10:04:23] or whatever [10:04:34] We can't form a comprehensive or accurate list [10:05:20] that's so lame. how do these machines get certified on windows with such widespread brokeness? [10:05:34] the driver that ships with windows matches whatever the hardware does. [10:05:46] until the next bios update? [10:06:59] We haven't been able to determine how Windows behaves on this front [10:07:17] But yeah, hardware is shit [10:07:27] and the user loses [10:07:50] One Acer I tested was trying to read lid state from a gpio that was off by 0x10 [10:07:53] since now things are broken out of the box until they make a change in configuration [10:08:19] ajax: I have an *awesome* X failure mode [10:08:24] Can I come and show you? [10:09:00] mjg59, ajax: i still think we should have the list and fall back to "make the user choose" [10:09:08] halfline: Not happening [10:09:19] mjg59: why not? [10:09:31] arghrarhgrh [10:09:36] halfline: The failure mode for "This device is not in the list" is "The user gets no video" [10:09:46] That's... not an acceptable outcome [10:09:49] this lack-of-control-click in g-t is infuriating [10:09:53] So all the code was removed from the kernel and won't be going back [10:11:12] i hope these closed laptops with backlights on aren't getting too hot... [10:13:34] mjg59: so here's a question for you... [10:14:03] mjg59: why can't we trust the backlight state unless the result is "no lit monitors" and then distrust it? [10:16:06] that's more or less what we do in el6 [10:16:19] we only look at lid state when there appear to be multiple connected outputs [10:16:33] great, that seems like the right thing to do [10:16:39] then we don't have to get the user involved [10:17:05] it does mean there's a failure mode where the firmware always reports the lid as closed [10:17:14] in which case plugging in VGA turns off LVDS. [10:17:27] which, also pretty lame. [10:17:56] Right. The problem with putting it in the server means that it's harder to handle the case where the desired outcome is other than the "right" answer [10:18:46] ajax: well you can tag the running system as having a faulty lid switch [10:18:52] no i can't [10:19:02] huh? [10:19:24] tell me how to know from software the difference between "this machine has a faulty lid switch" and "this machine is running with the lid epoxy'd shut" [10:20:29] when the machine starts ups, if there's no lit outputs, then turn on the lvds [10:20:35] and mark the lid switch state as "faulty" [10:20:45] then if they plug in a new monitor [10:20:52] not that the lid switch is faulty [10:20:55] *note [10:20:57] halfline: Why are you assuming that a machine that starts up with the lid closed is faulty? [10:20:59] and don't turn off lvds [10:21:12] people do that all the time, the loonies. [10:21:19] *** gozen (~gozen@dhcp-100-19-204.bos.redhat.com) has joined chat #X. [10:21:24] people start up the machines with the lid closed and no monitor attached to it? [10:21:27] yep. [10:21:33] yea that's kind of looney [10:21:56] i don't really care what happens if a user does that [10:22:18] ajax: Works fine with my own kernel [10:23:14] anyway, there's no way we can fix this in g-s-d [10:23:25] the only thing we can do is show the user the monitors capplet [10:23:33] and let them set the configuration right if it's wrong [10:23:50] we can't do that from the login screen atm though [10:24:21] so for the login screen we're probably going to have make sure we always show the login dialog on the non-lvds display or something [10:24:26] Yup [10:24:45] or maybe on all displays [10:24:54] have one login screen per display [10:25:37] i think the driver should be doing more than its doing though [10:25:53] it's the driver's job to shield the user and userspace from broken hardware [10:26:05] It's the driver's job to do that when it's possible for the driver to do that [10:26:11] it is possible [10:26:13] Nope [10:26:15] we just went over that [10:26:26] It's not possible to do so in a reliable way [10:26:32] Which means that userspace still needs to care [10:26:49] it's possible to do it a lot more reliably than it's doing it now [10:26:56] which means that user shouldn't have to care most of hte time [10:27:02] Except that if you paper over some of what userspace has to care about, userspace never gets fixed to deal with the remaining problem cases [10:27:10] right now they have to care all the time [10:27:13] Yes [10:27:35] It's better for the driver to be consistent than it is for it to be broken in a less deterministic way [10:27:42] i don't buy that, userspace gets fixed when bugs are filed... [10:27:53] i don't buy that either [10:28:05] I think the evidence is here [10:28:17] Given that userspace *isn't fixed* [10:28:29] The driver used to cover up some of the more obvious problem cases [10:28:36] And now it doesn't, because it can't do so reliably [10:28:51] cop out [10:29:13] So why isn't userspace already fixed? [10:29:15] *** mtgordon (~mtgordon@dhcp-100-2-185.bos.redhat.com) has joined chat #X. [10:29:23] mjg59: bugs weren't filed? i don't know [10:29:34] mjg59: because it worked until recently? not sure [10:29:42] It worked on a wider range of machines before [10:29:47] But the failure case was *far* worse [10:29:59] Now the failure case is mitigated, at the cost of userspace having to care more [10:30:24] i feel like the driver could do a better job without introducing bad failure cases [10:30:32] It's just really not acceptable for the driver to turn off displays that the user may be using [10:30:35] and i feel like userspace could care more [10:30:38] so how about we fix both [10:30:58] I don't think we have any way to do this in the driver without breaking some people [10:31:11] mjg59: it's really not acceptable for the driver to turn on a display that's closed either is it? [10:31:23] there's a little bit of fallacy here [10:31:32] pushing pixels at lvds doesn't require turning the backlight on [10:31:48] it does require powering the panel but that's not at all the same thing [10:32:02] well sure, but there's absolutely no point [10:32:10] when it's okay to push pixels to a display with no backlight on [10:32:25] it matters in the sense that doing so doesn't mean you'll slag the machine [10:32:27] that's when users start questioning whether their laptop inverter is dead [10:32:45] which is the usual argument for OH GOD WE CAN'T LIGHT CLOSED LVDS EVER [10:33:13] right i get where you're going, but that's a middle ground that never makes sense [10:33:24] halfline: We can't tell whether the display is actually closed or not. So we have two choices - either we light it (in some cases unnecessarily) or we don't (and sometimes the user ends up without a display) [10:33:27] because if the backlights on, then the user can't see the pixels [10:33:31] so there's no point in lighting them [10:34:14] mjg59: right, we just went over this. [10:34:23] we make an assumption that the user wants one lit display [10:34:26] at least one [10:34:30] it's not a crazy assumption [10:34:55] from there we say? does this laptop have any lit displays? [10:35:02] No! okay broken lid switch [10:35:15] then we tag the lid switch as faulty and never trust it again for that boot [10:35:23] halfline, a quick question: how does one do autologin in rhel6? [10:35:51] myllynen: put AutomaticLoginEnable=true and AutomaticLogin=myllynen in the [daemon] section of /etc/gdm/custom.conf [10:35:52] halfline: And then we end up flagging some machines as broken when they're not, which again violates user expectations [10:36:04] halfline, thanks! [10:36:42] mjg59: which machines? [10:36:58] halfline: If I boot in a dock before I've attached a cable, for instance [10:37:18] We can integrate more information, like "Is the machine docked" [10:37:36] mjg59: well that case isn't that important [10:37:41] and what's the failure mode of that case anyway? [10:37:51] The screen's lit when it's closed [10:37:59] which is the case we have now 100% of the time [10:38:11] Yes, but right now you have to handle this case [10:38:12] because the driver decided it hates users [10:38:21] Whereas if we implement that policy in the driver, you've already said that you don't care about that case [10:38:40] not it's not making any broad claim about how much it cares about that case [10:38:55] it's all about providing as good of a user experience as we can [10:39:08] there are cases [10:39:09] Providing the best user experience here means doing it in userspace, where you have access to more information [10:39:13] where we have to suck more than other cases [10:39:19] and we should handle those cases as well as we can [10:39:37] you have access to all the informaton user space does, except for the input of the user [10:40:06] Right now, we don't [10:40:12] why not? [10:40:24] There's no in-kernel indication of whether a machine is docked [10:40:41] The kernel knows a lot of things that it exports to userspace but doesn't export internally [10:40:42] we don't need to know that [10:40:58] Knowing if you're docked lets you deal with more of the "Is this lid really closed" cases [10:41:00] i don't know understand why that's not available to the kernel though [10:41:12] In that if you boot in a dock and the lid is closed you can probably assume that the lid really is closed [10:41:35] no you can't [10:41:44] if the laptop is docked but the lid is open [10:41:51] then you can't assume it's closed [10:42:00] In reality you can because any machines that have docks also have reliable lid switch indication [10:42:24] really? [10:42:34] As far as I've been able to determine [10:42:47] so we should fix the kernel then for the dock case [10:43:17] But you *still* don't want to do it in the driver because you want it to be easy for the user to override the remaining cases [10:43:36] I mean, doing this in the session isn't hard [10:43:44] we're just talking about defaults here.. the user will always be able to override, right? [10:44:03] It's not obvious how the user overrides the kernel if the kernel is reporting that the output is disconnected [10:44:36] We'd need another output state [10:44:44] when would the kernel ever report the output as disconnected? the failure case we identified before was the kernel lighting the monitor with the lid closed [10:45:05] The previous behaviour was that LVDS would be reported as disconnected if the lid is closed [10:46:14] so you're worried about the case where the lid switch says it's closed, but it's actually open ? [10:46:40] Yes [10:46:53] That's the bad failure mode [10:47:20] so that's not a problem because we boot up, we detect that the there are no outputs and the tag the lid switch as faulty [10:47:32] and then treat it as always open [10:47:40] and the user can override that [10:48:19] No [10:48:22] no? [10:48:42] If we boot up with a faulty lid switch and there's a monitor plugged in, the heuristic won't trigger and we'll mark the LVDS as disconnected [10:48:53] Which sucks if the user actually wants to use the screen [10:49:30] so instead of marking it as disconnected, we mark it as connected but inactive [10:50:08] of course plymouth will then light it up [10:50:10] What does userspace do in that case [10:50:11] Right [10:50:56] maybe plymouth shouldn't light it up [10:51:16] i just added that code since i was giving a demo one day and it wouldn't go to the projector [10:51:47] *** ofourdan is now known as ofourdan|brb. [10:52:06] not sure [10:52:13] anyway it's clear this is a complicated problem [10:52:20] i don't think this is something we can solve right away [10:52:45] and it needs fixes in gnome, kernel, and maybe plymouth and X too, who knows [10:53:03] I don't think there's any problem with the screen being inappropriately lit during boot [10:53:26] well it wouldn't be a problem, except [10:53:37] then gdm puts the dalog on it [10:53:39] *dialog [10:54:18] halfline: Yeah, so userspace should be smarter :) [10:54:24] agreed [10:54:29] so summary is [10:54:33] 1) gdm needs to be smarter [10:54:40] 2) kernel needs to be smarter [10:54:56] 3)plymouth may need to be smarter [10:55:15] but you still don't agree with 2)? or do you now? [10:56:01] My disklike of 2 is now pretty much limited to us effectively having to special case LVDS/eDP by having a "You probably don't want to use this display" state [10:56:24] well i wouldn't call the state that [10:56:37] it's more like a "you can't reliably trust lid switch state" [10:56:52] Sorry, I mean the connector state [10:57:02] and then let the drm driver do the heuristics do the rest [10:57:13] We can't report disconnected because then you can't turn it back on [10:57:47] the drm driver always has a "connected but not lit" state [10:57:51] s/always/already/ [11:05:28] in that those are separate axes, yes. [11:05:52] halfline: Yeah, but "Connected but not lit" means "Light me" [11:06:01] connected/disconnected/unknown, and then enabled/disabled. [11:06:15] Whereas what you want here is "Connected, not lit, don't light me unless you really really want to" [11:09:12] adding additional info would help userspace do a better job, yea [11:09:32] But that feels ugly [11:10:17] *** ofourdan|brb is now known as ofourdan. [11:11:29] mjg59: it's an ugly problem [11:12:32] far more ugly to just throw our hands up and not fix the issue though, or add all this crap to userspace [11:16:36] Userspace is going to have to deal with some amount of crap anyway [11:16:52] I'd prefer to just pass it everything we know and let it make its own mind up [11:18:28] i agree with the first thing you said [11:19:01] Otherwise we end up adding to the interface just to indicate to userspace that we don't know [11:19:14] When instead userspace could just assume that we don't know [11:19:14] what's wrong with that though? [11:19:37] It seems kind of redundant [11:19:42] there are times when you do know [11:19:46] and times when you don't [11:19:56] most of the time you do [11:20:00] There are no cases where we know the truth [11:20:07] Or, rather, that we know we know [11:20:25] I've got a machine that reports open/closed correctly until you close it for the first time [11:20:28] It never sends an open [11:20:43] Turns out that it's missing a GPE handler for that [11:22:08] okay, well let's not do the the interface change then [11:22:19] doesn't preclude doing all the other fixes [11:22:37] that's just a hint to e.g. not light up plymouth unncessarily [11:23:29] If userspace is special casing LVDS anyway, userspace should just go all the way [11:23:45] i don't think userspace should special case lvds [11:23:57] Well, it has to [11:24:07] Otherwise you'll turn on LVDS all the time [11:24:08] no, let me be clear the kinds of fixes i think should go in for userspace [11:24:45] 1) fix gdm to always show login screen on all heads [11:25:22] 2) make sure there's a way to "make default" monitor configuration in monitor capplet [11:25:29] so it's settings get propagated to gdm [11:26:02] potentially change plymouth to not light up connected/disabled monitors [11:26:05] whot: https://bugzilla.redhat.com/show_bug.cgi?id=628528 ??? [11:26:17] (the last one should have a 3) in front of it) [11:26:30] those are the userspace changes i think we should do [11:26:32] halfline: (3) would be a requirement, otherwise you'll have exactly the situation you have now [11:26:54] we'll have exactly the situation we have now for a small subset of cases [11:27:03] but all ther cases we'll behave properly [11:27:08] No [11:27:09] s/ther/the other/ [11:27:25] Because we'll either report LVDS as connected and enabled or connected and disabled [11:27:45] So if plymouth always changes the latter state to the former state then we win nothing [11:28:10] no, if the kernel has determined lid state isn't faulty then it can report it has disconnected [11:28:15] s/has/as/ [11:28:43] anyway, 3 is probably a rigth change anyway [11:29:09] halfline: How does the kernel determine lid state isn't faulty? [11:29:58] well there's a few checks it has to do [11:30:23] like i mentioned earlier, it knows it's faulty if there's no connected outputs at boot [11:30:46] rather, if the lid state reports closed, and there's no external monitor plugged in -> faulty [11:31:15] halfline: Yeah, but that doesn't mean that in other cases we can assume that it's correct [11:31:18] *** mcepl has left chat #x (Read error: Connection reset by peer). [11:31:53] i guess we'd have to do the matrix of possible lid states and possible monitor configurations [11:32:06] and figure out what to do for each step [11:32:09] If I boot a faulty machine with a plugged in monitor, flagging LVDS as disconnected is going to make me sad [11:32:24] along with the ramifications of being wrong for that case [11:33:39] oh because if you undock there's no way to light up the lvds [11:33:54] Well, maybe I want to use dual head? [11:34:09] hmm [11:34:35] So there's basically no situation in which we can report disconnected [11:34:38] alright, i'll concede we need to fix plymouth [11:34:40] Which means userspace needs to special-case LVDS [11:34:56] So why not do the rest of the special casing there as well? [11:35:13] not sure how the second follows from the first? [11:35:31] the plymouth code is weird anyway. plymouth normally uses the exact configuration it was handed [11:35:37] except in this one particular [11:35:38] case [11:35:39] Plymouth should turn on "Connected but not enabled" unless it's LVDS [11:35:48] where i added some code to have it muck with the config [11:36:03] i don't know that that's true [11:36:13] why should plymouth ever turn on monitors that aren't enabled? [11:36:20] if the kernel didn't enable them, then why should plymouth? [11:36:53] Hm. I guess that'd work. [11:36:55] the code was basically added to work around a bug in the kernel where it wasn't enabling hte projector [11:37:07] that bug is probably long fixed now [11:37:15] and the code was always questionable [11:40:11] alright, so to summarize, we need 1) 2) and 3) above and a pile of kernel fixes [11:40:13] agreed? [11:40:32] * halfline starts to think about lunch [11:42:01] halfline: I'll think some more about the kernel side [11:42:46] Ok, I know why I dislike it in-kernel. If you don't have appropriate userspace then it becomes a pain in the ass to get your LVDS to turn on. [11:43:06] how so? [11:44:17] The kernel reports it as connected but disabled. How do I turn it on? [11:44:29] the monitors capplet [11:44:41] Right, hence appropriate userspace [11:44:48] fbset! (gunmouth) [11:44:56] oh i see what you mean, but we already have that userspace [11:45:08] i mean that works today [11:45:11] We do, but we (sadly) are not the entire Linux market [11:45:33] The safe thing to do is to enable the output, and then userspace can disable it if it provides a way for it to be reenabled [11:45:42] well the other parts of the market can add the userspace they need [11:45:54] or patch their custom already heavily patched kernel [11:46:08] Yeah, but the people running 2.6.38 on their fc8 userspace get sad [11:46:15] Which isn't a case *I* care about [11:46:19] But is a case Linus cares about [11:46:21] me either [11:46:57] mjg59: that case doesn't matter because they didn't have kms [11:47:30] what i mean is, they're already boot with nomodeset or X isn't working [11:47:55] halfline: It's very difficult to push a behavioural change to the kernel that's predicated upon you having certain userspace [11:47:55] since their X driver is going to try to set a mode [11:48:24] and just a big behavioral change was already pushed predicated on a bunch of userspace heuristics getting added [11:48:38] s/just/yet/ [11:48:54] halfline: Yes, since the alternative was "People can't use their displays" [11:50:25] mjg59: well, it's not too hard of a case to make i think [11:50:33] the prediciation isn't a hard-dep [11:50:43] if the userspace isn't there, things don't fail horribly [11:51:04] they just work better with some userspace knob to turn it on [11:52:21] i mean if the user is using X then they have xrandr at a minimum [11:52:58] if they aren't using X, the failure case isn't that bad, and they're doing something so custom anyway, that they will do whatever they need to do to get things working well for them [11:54:19] halfline: It's a change that results in some existing setups failing in such a way that the user is missing a display [11:54:29] That's... not an easy argument to make [11:55:00] no they'll still have a display [11:55:13] just *one of* their displays might need to be explicitly enabled [11:55:22] Right. And that's a problem. [11:55:43] We break existing setups and Linus reverts the code [11:57:06] *** assassin has left chat #x (Ping timeout: 240 seconds). [11:57:19] you're argument is "we made some changes a while ago that turn on all displays. Because we did that, even though it wasn't the best thing to do, we can't ever fix it to turn off the ones it's supposed to now" [11:57:21] right? [11:58:29] that sounds pretty bullshit, but i don't know the politics of the kernel eco system [11:58:38] anyway, hungry. i'm going to get some lunch [11:58:44] I'm saying that the only safe behaviour from the kernel is to enable all displays [11:59:14] except for the cases where it doesn't enable the displays [11:59:18] like tv etc [11:59:42] Which I'd argue is a bug [12:00:04] ajax would argue with you about that i think [12:00:10] He may well! [12:00:24] but anyway, we've been at this for hours :-) i'm ready to move on to other things [12:00:26] like food [12:00:40] bbl [12:00:47] But "Light up, let userspace turn off things it doesn't want" is a much safer option than "Don't light up, rely on userspace to turn things on" [13:17:05] mjg59: *shrug* [13:17:32] mjg59: userspace isn't the only one uses the displays [13:17:49] on the other hand fbcon is always cloned, so it's running in a sort of "degenerate" mode anyway [16:25:35] someone should propose an LPC desktop miniconf session on laptop lids [16:27:00] won't help. [16:27:14] the only thing that helps is shooting bios engineers until they learn [16:33:08] well we can at least tell the desktop groups what to expect ;-) ... [15:13:29] halfline: hey :-) [15:14:06] I wanted to quickly ask, I noticed GDM in F14 doesn't use an external screen if the laptop screen is off. Was that fixed by one of the updates I saw recently? [15:19:45] thos: that's an X change, one sec [15:25:07] thos: http://people.freedesktop.org/~halfline/laptop-display-on-when-lid-closed.txt [15:25:32] thos: i'm going to eventually make gdm just paint login screens on all available monitors [15:25:47] not sure exactly when .... [15:38:10] thos: so, basically gnome-settings-daemon now has the appropriate code to deal with it? [15:38:45] halfline: no it's basically broken right now [15:39:07] halfline: basically the kernel used to handle the case [15:39:14] thos: oh, I thought I saw an update to g-s-d that might have mentioned it [15:39:15] halfline: and they dropped the code to do that [15:39:33] halfline: oh really? [15:39:34] * halfline looks [15:41:42] halfline: oh bastien did do an update a couple of days ago (bug 623824) [15:41:46] halfline: let me see what the update is about [15:42:01] thos: also, looks like you already pasted that conversation as http://people.freedesktop.org/~halfline/the-troubling-tale-of-fibbing-laptop-lids.txt ;-) [15:42:24] halfline: thos: ah! i thought i had and couldn't find it [15:43:42] halfline: part of the problem of having like 4 people pages with various irc conversations dumped on all of them... [15:47:01] halfline: ah okay so that gnome-settings-daemon update might fix things okay [15:47:12] halfline: it will make it do "spanning" by default [15:47:26] halfline: then the login screen will end up on the monitor the pointer ends up on [15:47:42] halfline: which will normally be the external monitor, since the external monitors is usually bigger [15:47:48] halfline: and the pointer starts out centered [15:48:04] halfline: it's still going to be broken for some users though [15:48:38] halfline: (users who compulsively move their pointer at startup, and users with smaller external monitors than laptop monitors) ---- [16:25:26] gdm also needs to be changed to put it's login screen on every monitor before we have a good multi-monitor story there... [16:25:47] halfline: no I doubt it [16:26:04] doubt what? [16:26:22] If I have two side by side monitors I don't want two prompts [16:26:33] we don't really have much choice unfortunately [16:26:41] that's weird [16:26:44] anyway [16:26:51] yea i had a long talk with mjg59 about it at one point [16:27:30] basically there are a non-negligible number of cases where one of hte monitors in the listed layout won't be visible to the user [16:27:41] whatever man [16:28:03] the we can't tell if lid is closed case [16:28:13] yup [16:28:27] halfline: OK, so you log in from the random monitor, and the panel appears on the invisible monitor [16:28:27] the broken-hardware-broken-kernel-just-give-up [16:28:29] case [16:28:34] yeah someone should fix that [16:28:36] halfline: how does the user proceed? [16:28:36] anyway [16:29:38] anyone for fixing the primary? [16:29:39] owen: not sure [16:29:53] owen: i guess they hit hot keys or something [16:29:56] press a key for 'I need a login, here' ? [16:30:10] touch screens [16:30:23] halfline: it seems pretty parallel before or after login [16:30:42] owen: yea you may be right [16:31:24] alright, i cede this debate [16:31:27] halfline: prompting on every screen just isn't right. if this is really a serious issue that we can't fix properly there are other options. [16:31:37] (we should fix the darn lid thing) [16:33:01] ok so no takers on the primary thing [16:33:54] don't think the laptop lid thing is going to get fixed...see http://people.freedesktop.org/~halfline/the-troubling-tale-of-fibbing-laptop-lids.txt for the conversation [16:34:32] it needs to get fixed [16:34:34] halfline: OK, ,maybe it won't get fixed by miraculously hoping that we figure out how to work around all bios bugs [16:34:52] but that doesn't mean that we can't figure out a way to get an expanding circle of hardware that *works* [16:35:14] Starting off by having a solid definition of what a laptop working with our OS means [16:36:52] yeah we can say to the world if you want a perfectly working system go buy A. it is not acceptable to say to the world that we can't make a working system until they all work the same. [16:36:55] If we can't tell if the lid is open or closed, we can't hibernate reliably if we run out of power while suspended, etc, then we can't *design* around that, we have to declare that as broken. You don't get the right experience if you have a broken laptop [16:38:19] well the problem is now out of the box hte laptop lid is lit up unconditionally when hte laptop lid is closed [16:38:25] * mccann adds fixing primary to his todo list :( [16:39:09] so i guess we need to ask if the lid is closed and avoid putting the login screen there in that case [16:39:18] and hope that it's telling us the truth [16:39:40] the kernel used to not light up the laptop lid if the lid was closed [16:40:13] now they will always light it up [16:40:28] https://bugzilla.redhat.com/show_bug.cgi?id=531318 [16:40:30] Bug 531318: medium, low, ---, ajax, ASSIGNED, uses monitor even when lid is closed [16:41:58] yea i imagine that's going to get wontfixed eventually [16:42:04]