released. Reproducible: Always
Reassigning to x11 herd.
As if we didn't already know... And FYI, it's in the x11 overlay.
He knew that already: https://bugs.gentoo.org/260509#c2
fixed? is it in portage? because 'in overlay' doesn't count.
What do you expect to achieve by opening bugs about something you know we're already aware of? It's just a time sink for me to deal with this kind of thing instead of get actual work done...
it allows me to know the status of the bug. It allows me to know whether or not you would prefer to spend your time complaining about the existence of a bug than doing your job, fixing the bug. It allows me to know whether or not I have to spend time doing your job to fix the bug, since it is my job to make sure that this kind of thing is handled in my tree. right now you are the kind of person that thinks being a volunteer is a privilege and not a responsibility. You think that because you don't get paid that you don't have to do it. I assure you that if you look at most non foss volunteer jobs you either have to do your job or quit. it is the same in open source. perhaps I'm judging you wrongly. but you've spent more time discussing the existence of a bug than working on it (my perception as the other bug hasn't been updated). being cc-ed to a bug doesn't require you to respond to it daily. it requires you to report if their is something to report. you've also closed a bug that wasn't fixed as fixed waisting my time and yours. you could have chosen to ignore the bug until you have something to say, instead you choose to waste your time trolling bug reporters who may have legitimate reasons to track version bump progress. your awareness of the issue isn't my concern. your devotion to any actual responsibility is. and don't go about saying, "don't talk if you aren't willing to help". I'm helping in my own way. if you'll excuse me I promised zmedico a patch and documentation for said patch, to portage. So I'll just be blunt, can I expect at least a masked 1.6.0 in the tree within a week? or do I have to do it myself. now, are you going to continue to waste both our time?
Guys, this becomes ridiculous. If you don't have to add valuable stuff to this bug, leave it alone and I gonna mark it as fixed as soon as xorg-server-1.6 hits portage. Come on, let's concentrate on issues which move gentoo forward.
Tree ETA? (Even if masked.) I'd sure like to get panning back, is why. And I've a new ati/radeon driver and am running .29 git kernels, and am hoping the new xorg-server is the piece I need to cure the mtrr shortage 1.5.3 (-r2) keeps complaining about, and kms sounds like fun, and... and... I'm sure you guys have reasons xorg-server-1.6 and any dependencies aren't in the tree yet, but having some idea of estimated time of arrival, 2 days, 2 weeks, 2 months, not until 1.6.1, etc, would be nice. Yes I know it'd be "estimated", that's what the E in ETA is about. =:^)
If it were only up to me, I'd wait until we stabilized 1.5.3. I feel pretty confident about writing the upgrade guide and giving arch teams a final list within a week or two. I would say we can aim for putting 1.6 in portage (still with a p.mask though) within a month. Donnie? Do you see things differently? Cheers
(In reply to comment #9) > If it were only up to me [...] Thanks. Just the sort of info I was after. =:^) (Pre-thanks to Donnie and for any further updates too. I'll refrain from cluttering the bug every time, but it's appreciated! =:^)
(In reply to comment #9) > If it were only up to me, I'd wait until we stabilized 1.5.3. I feel pretty > confident about writing the upgrade guide and giving arch teams a final list > within a week or two. > > I would say we can aim for putting 1.6 in portage (still with a p.mask though) > within a month. > > Donnie? Do you see things differently? For everyone else's benefit, I blogged about the issues blocking 1.6 a while ago <http://dberkholz.wordpress.com/2009/02/26/xorg-server-16-preview-in-x11-overlay/>. I don't see any reason to hold off getting it straight into ~arch as soon as those issues are fixed. Remi, what are your reasons for wanting to do things that way?
(In reply to comment #11) > I don't see any reason to hold off getting it straight into ~arch as soon as > those issues are fixed. Remi, what are your reasons for wanting to do things > that way? Not strictly a time-based thing, it's just an estimate of the time it could take us to fix those issues. As for me, I'll keep working on 1.5.3 until I hand off a stabilization list to the arch teams.
*** Bug 267006 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > *** Bug 267006 has been marked as a duplicate of this bug. *** > Apparently 1.6.1 fixes bug 262512 based on comment in bug 267006. Changing summary because I would think that 1.6.1 is the new target for the tree now. Sorry if this is incorrect.
Confirmed, imo 1.6.1 is the way to go. It fixed X resetting (on 2.6.29) and freezing (on 2.6.30) for me. Right now I have a stable system with xf86-video-intel-9999 (fixed some 2.7.0 bugs) and 2.6.30_rc2-r7 patched with the i915 tiling fix. To get something useful out of this bug, what about transforming it into a tracker and make it our new stabilization effort?
('installed', '/', 'x11-base/xorg-server-1.5.3-r5', 'nomerge') pulled in by <x11-base/xorg-server-1.5.99 required by ('installed', '/', 'x11-drivers/nvidia-drivers-173.14.18', 'nomerge') Can you provide any evidence for this blocker? As far as I know current Ubuntu users can use this driver with xorg-server 1.6.0
(In reply to comment #16) > Can you provide any evidence for this blocker? As far as I know current Ubuntu > users can use this driver with xorg-server 1.6.0 Please don't highjack this bug. Please open a new one to discuss this with the nvidia maintainers. Thanks
Created attachment 189962 [details] /xorg-server-1.6.1.ebuild proposed ebuild for x11-base/xorg-server-1.6.1 The difference to the ebuild in the x11 overlay is that it passes --enable-dri2 to configure, in order to allow xf86-video-intel-2.8 branch to build (dri1 support was dropped there). diff --git a/x11-base/xorg-server/xorg-server-1.6.1.ebuild b/x11-base/xorg-server/xorg-server-1.6.1.ebuild index f943575..6feac8f 100644 --- a/x11-base/xorg-server/xorg-server-1.6.1.ebuild +++ b/x11-base/xorg-server/xorg-server-1.6.1.ebuild @@ -315,6 +315,7 @@ pkg_setup() { $(use_enable !minimal xfree86-utils) $(use_enable !minimal install-libxf86config) $(use_enable !minimal dri) + $(use_enable !minimal dri2) $(use_enable !minimal glx) $(use_enable xorg) $(use_enable nptl glx-tls)
Slightly unrelated to this bug, but can you please restore 1.6.0 ebuild on the overlay cause now we are forced to downgrade to 1.5.3-r5 since 1.6.1 is masked. :\
Just unmask it... that's the point.
(In reply to comment #20) > Just unmask it... that's the point. No. Since you guys think that this packages should stay masked due to multiple bugs, it would be nice to restore the old one. Forcing users to unmask and test 1.6.1 is not that handy for their mental health :) . Some of them might want to test 1.6.1 but others just want to keep their systems in a more sane situation
1.6.1 is actually more sane than 1.6.0.
It's masked because I'm working on moving the ebuild from the overlay to portage. No other reason. If anything, 1.6.1 works better than 1.6.0. Please unmask it.
Ok, xorg-server-1.6.1 is not on the overlay anymore. Do you recommend to use 1.6.1.901-rX packages?
Definitely, 1.6 should be ready for wider testing. The only thing that needs some thoughts is the DontZap stuff which we need to really figure out. But in any case, it's a minor problem which we should be able to work around easily. Thanks
(In reply to comment #23) > It's masked because I'm working on moving the ebuild from the overlay to > portage. No other reason. If anything, 1.6.1 works better than 1.6.0. > > Please unmask it. > 30 days to move it? Unmasking it won't do a thing unless the dependencies are in the tree. I have been looking for the dependencies of 1.6.1 for the last 2 weeks. 1.6.1 is no longer in layman. Guess I'll step up to 9999.
(In reply to comment #26) > 30 days to move it? Unmasking it won't do a thing unless the dependencies are > in the tree. I have been looking for the dependencies of 1.6.1 for the last 2 > weeks. 1.6.1 is no longer in layman. Guess I'll step up to 9999. > It was added to tree, unmasked, and bumped to 1.6.1.901-r3. Unmask that if you want to use the 1.6.2 pre-release.
All the deps for 1.6.1.901-r3 are already in portage. It's safe to unmask. I'm only keeping it masked until I get together a "1.6 upgrade" guide along with xkeyboard-config 1.6 which will change the default behavior of ctrl-alt-backspace. NB, adding Xdmx bugs in the tracker, apparently they can be fixed, let's target them for 1.6 Thanks
@Rémi Cardona Xorg now ignores Ctrl-Alt-Backspace by default, is it the same with Ctrl-Alt-Fx ? Because I just updated xorg-server to 1.6 and it seems so on my computer.
http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml
@ jcdemay: I believe it depends on your graphics card and whether the driver is RandR compliant or not. RandR allows dynamic X configuration when a monitor is hotplugged, among other things, and new enough desktop environments should come with a widget. For KDE 3 and 4 that's krandrtray, with the same settings available in kcontrol, tho at least the kde3 version doesn't work so well with dual monitor or with the latest fanciest RandR version and features). I have better luck with the xrandr command, however, run in a terminal window or scripted. I run it scripted (of course running it many times from a terminal window while developing and testing the scripts), with kmenu items invoking the scripts, and khotkeys setup to invoke those menu items. I could thus set it up to invoke with the same hotkeys in the same mode cycle, if desired, but chose to set it up with a specific hotkey for each mode, instead, so I don't have to cycle thru them to get the one I want, if I know which one it is. There is of course an xrandr manpage to help you figure it out. Duncan
@Duncan, No, ctrl-alt-backspace is controlled by the server directly. Video drivers have absolutely nothing to do with zapping. Please read the linked doc, you'll see that XKB (the X Keyboard extension) is the one responsible for this behavior. Thanks
@ Remi zap is server, you're right. However, if I didn't misunderstand his question (you or I did, I don't know which), he said that don't-zap is the default now (IOW he knew that), and wondered if don't-zoom is too (that was his question, zooming seemed broken and he wondered if it was like zap, which he knew about already, or not). So I answered the zoom part which I though he was asking, and you answered the zap part, which you thought he was asking. It's all good, there's an answer either way now, and others obviously keep discovering the bug as I see the new CCs, so it should be answered. (At least, if CTRL-ALT-+/- zoom wasn't supposed to break, then the video-ati driver is certainly broken on r200s at least, because it sure doesn't zoom any more with those sequences here and hasn't since the switch to RandR based configuration, so that's what I attributed it to. Are you saying server-based CTRL-ALT-+/- zoom still works on other RandR based graphics drivers?)
I have no idea about zoom. I don't use it. But please, this is a tracker bug. If you have any issues, please file another bug and we'll look at it. Let's keep this one on topic Thanks
All the bugs that needed fixing are fixed, xorg-server 1.6 is unmasked. Closing. As for libxcb & friends, those will be taken care of separately as they not linked in any way to xorg-server 1.6 Thanks
