today was busy. but it seems i got nothing "real" done. phone calls, emails, prep work for 4.x and some time spent with the p-man. but very little code. blarg. i'm not sure if it's exactly healthy to measure my life in terms of lines of code, but there you go.
we've got a nasty bug in plasma that's showing itself with intel chipsets and the new xrandr which allows for hot plug monitors. essentially the driver lies to us and says that the newly plugged monitor and the existing one (e.g. the built in lcd on the laptop) are both at (0, 0). so plasma happily puts two desktops there, which leads to neat overlapping desktops. and by neat i meant "what a horrid bug".
i wrote to Keith Packard about it and his reply was essentially that it's up to me to find some way to work around it because he can't guarantee the position or order of monitors at runtime, though i find it hard to believe that even the driver itself doesn't know at *some* point, especially ones both are actually advertised as displaying content. apparently Keith and friends consider this interesting behaviour "par for the course" and expected. i'm disappointed, and i'm not the only one given what i've heard from others working on other projects who are dealing with this same issue. so much for sane software, right? not sure how i'm going to hack around this.
i filed a bug against gtk+ and their argb problems. the gtk+ people have said that they don't accept that the code in plasma is "valid" even though it works with every other toolkit out there. nothing like sluffing off your crashers with "well, you shouldn't do that anyways!" in any case, frederikh came up with a small patch for x.org that could prevent this being a problem for anyone, which is probably an even nicer approach since it fixes things lower in the stack rather having to rely on the good sense of the larger number of people writing code higher up.
good news, however: i got email from nvidia today (hi Ignacio!) letting me know that the argb bug has been fixed. the next driver release will contain the fix, and they'll be letting me know when that comes out so i can help point people with these issues to it.
interesting that the open source projects are less responsive when dealing with on this matter.
in other news, i'm supposed to be doing an interview over skype with the linux action show boys any minute now to talk about the rc1 debacle and kde4 in general ... i've settled back with a glass of wolf blass '04 unwooded chardonay and some cheese and crackers to get in the mood. p is asleep and the house is quiet and warm and clean.
i hope all of you have an excellent weekend. =)
Subscribe to:
Post Comments (Atom)
21 comments:
Also, you'll be pleased to hear that the guy who fixed your bug is also named Aaron.
-- Aaron (the one at NVIDIA)
was the ARGB problem a X.Org, GTK+ or NVIDIA bug?
I actually used to see that monitor overlapping problem with both my ATI and NVidia cards at one point, but only with odd misconfigurations on my part. I find it very hard to believe AMD and NVidia can manage the issue, and a big mega corp like Intel can't. buggy CPUs, Buggy chipsets, and now buggy drivers, who would have guessed.
@anonymous:
> was the ARGB problem a X.Org, GTK+ or
> NVIDIA bug?
there were/are several different bugs with argb visuals affecting each of the above pieces of software. nvidia has fixed theirs, still waiting on the others.
@Aaron-from-NVidia: dude, you rock. thanks for the fix =) if you're ever at an event that i'm also at, please find me and i'll buy you a beer (or whatever you drink)
Is there a way to manually detect how many displays are present, and set each one on a different screen?
Anyway, I'm pretty frustrated that the GTK guys are not going to really deal with the situation. Maybe they're jealous of plasma?
Also, maybe ATI should learn a few things from nVidia lol.
Hi,
I'm still hoping that my laptop with intel card can do hot-plugging of my svhs/svideo outputs. So I have a little interrest in the topic ;)
I read your mail and I considered the statement you said Keith made; that the driver can't determine where the new monitor is physically located. And he is right, nobody but the user can do that.
Thinking about what *I* would like to see happen is this;
1) I plug in the new thing
2) [someone] automatically places it semi-random left or right of my current setup
3) Plasma places a dialog on the new monitor with the overview of monitors, allowing me to reposition it to the left or right/etc of the current monitor.
This dialog, when applied, would move the coordinates of the new monitor to the correct position.
Now, I'm not sure if you have to talk to X (and thus the Intel driver), if you don't then I agree with Keith, who cares about what default he gives.
If you do have to tell the driver about the new location, then Keith is being anal by not providing sane defaults. I mean; *any* default is better then having two overlapping displays.
The thing about Intel sounds strage: first of all, why can the Nvidia guys fix it and the Intel people can't?
Second, the xrandr tool can differentiate between the two monitors (you are able to control both with different settings), so even when there is no order internally, the driver at least must have one way to distinguish the output of both!
Additionally, the closed ATI drivers have a "identify this display" button which shows numbers on the displays - the Intel drivers should be able to provide something similar.
To summarize, other drivers provide this option, and internally Intel must have some way as well to distinguish both outputs. So all is missing is a way from Intel to provide this information to other programmers as far as I understand it.
Sad that they are not willing (?) to fix that.
@Aaron J. Seigo
I replied to your comment (n.2) in the bugzilla.
Maybe I'm stating the obvious but I hope it helps.
Alberto (aka tseliot)
The question is now: when will TT use the argb visuals? I just filled yesterday a wish for KWin's decoration to try to work somehow without them: http://bugs.kde.org/show_bug.cgi?id=153664. For the poor stylers sake, I hope they will be used soon:)
Did you CC: the xorg mailinglist when emailing Keith Packard about the problem? He might not have a solution, but there are other people from Intel on that mailing list who might.
wow you drink australian wine? or does wolf blass have vieyards in canada?
I'm very alarmed about the new file-dialog: It doesn't provide a function to switch to "adress-bar mode" where I can type an adress, which means it now lacks support for sftp://, ftp:// and all other kio-slaves except file://. It's also not quite usable for me because I can't type an adress. I think this should be fixed as soon as possible.
@blueget: 'I'm very alarmed about the new file-dialog: It doesn't provide a function to switch to "adress-bar mode" where I can type an adress'
you can either type that right into the Location bar or you can put your mouse anywhere to the right of the breadcrumb and click to get the editable bar at the top.
I'm here patiently waiting for RC2, but needed to say that as an nVidia user I'm proud that the company has such a stance on helping out. It's things like this that really help push everything forward.
aaron++
I'm trying to understand how the intel multiple screen issue is a bug. If you use xrandr on an nvidia machine to set both screens at (0,0), then won't it behave and look exactly the same?
If so, then the only bug is that the default settings are different btw. nvidia and intel. Which is not really a bug, because if I plug in a projector as my second screen, then there's a good chance I want it to display exactly what I have on my current screen, which is done by setting the origin of both monitor and projector to be the same.
Very interested in some feedback.
@metrics: "the default settings are different"
that's right, and that's the bug. it shouldn't default to such an inane layout. if the user wishes to do something odd, go for it.
"Which is not really a bug, because if I plug in a projector as my second screen, then there's a good chance I want it to display exactly what I have on my current screen,"
in which case it should be advertised as *one* screen. not two that is actually one.
that said, i sometimes want to have the same thing on the projector as is on my screen but often i do not. the only reason that's so common with x.org today is because our presentation software sucks and doesn't take advantage of having xinerama screens. impress is finally fixing this in their implementation, i truly hope kpresenter gets the same feature eventually.
" which is done by setting the origin of both monitor and projector to be the same."
this is an implementation detail and should not be exported into the user space. now, if the two monitors have different resolutions but are showing the same area... i do consider that to be a bug because either one monitor (the smaller one) will only be showing some of the contents or the other monitor (the bigger one) will have dead areas.
@aaron: Thanks for some clarification. I see the point that you're getting at. I agree that better defaults would be better. However I don't see any solution to the projector/monitor situation...remember, it's not always a presentation you want to show.
If you have two different screen resolutions, there is no other option but to have some dead area or some area missing. But thats really a whole different bucket of bits.
NVidia bug fixed:
http://www.phoronix.com/scan.php?page=article&item=946&num=1
Post a Comment