http://www.phoronix.com/scan.php?page=a ... r_16&num=1
http://www.phoronix.com/scan.php?page=n ... &px=NzA5MA
Please, please, please put an ebuild at least in the x11 overlay



To compete with Remi’s post about getting xorg-server 1.5.3 stable in Gentoo, here’s one about getting xorg-server 1.6, which was released today, into testing in the main tree. We’ve been maintaining the 1.6 release candidates in the x11 overlay for a while now. Tonight I added the final release to the overlay. What’s left before it can move to the main tree? Here’s what I can think of, offhand:
The new XRandR stuff needs to get released upstream (randrproto, libXrandr, xrandr). Right now we’ve got the xrandr userland tool depending on live git of libXrandr, which won’t work for the main tree.
We need to sort out the issue with XCB’s Xlib library renaming forcing recompiles of practically everything. This is becoming more and more of a blocker because now libXext 7.0.5 requires a new libX11. I think giving ourselves a hard blocker on 1.6 from this will help us get it fixed. See bug #248743 to track progress on this.
The server now has a fix to keep looking for HAL if it’s not running when started. Should we change /etc/init.d/xdm to compensate for this change by no longer depending on hald, thus allowing gdm/kdm/etc to start earlier? This will give us one of the steps taken by the fastboot work seen lately in Moblin and elsewhere.
I think Remi’s going to add xf86-video-intel 2.6.2.
Our xinit is crazy stale, mainly because we patch it like crazy and I don’t like porting those. I’d like to get it updated to a current release for 1.6. In the longer term, we need to merge distro-neutral parts of our work upstream, but that’s not a 1.6 blocker.
To sum up, you can try xorg-server 1.6 now by adding the x11 overlay with layman, or you can wait for the above issues to get solved, and it will show up soon in testing in your main tree.


Code: Select all
> checking if xorg-macros used to generate configure is at least 1.2... configure: error: configure built with too old of a version of xorg-macros.m4 - requires version 1.1.0 or newer

how I see it, the logical solution is to emerge latest m4 version and then emerge latest util-macros version and then retry emerging inputproto0000000000000 wrote:Anyone else unable to emerge randrproto-1.2.99.4?
Getting 404's from all the servers on that one when trying to emerge xorg-server-1.6.0
edit: got randrproto from a different location and installed it, now emerge fails on inputproto-9999 saying xorg-macros.m4 is too oldany ideas?Code: Select all
> checking if xorg-macros used to generate configure is at least 1.2... configure: error: configure built with too old of a version of xorg-macros.m4 - requires version 1.1.0 or newer
couldnt really find much on this elsewhere
You might want to work backwards with xorg-server and the intel driver until you come across a combination that works well for your system, then freeze it with package.*.mrsaccess wrote:I tried 2.6.2 on xorg-server 1.5.3-r2. Painful experience. I had to do an interactive boot in order to avoid xdm loading so I could get to a console and revert to the bad yet working at least in some ways 2.6.1.
Card X3100 (GM965 that is I think).
going backwards never helps anything in the long run, make sure you have xorg 1.6, latest intel driver, and latest libdrm with matching kernel drm module, then go to #intel-gfx and talk to the devs to fix any regressionsaudiodef wrote:You might want to work backwards with xorg-server and the intel driver until you come across a combination that works well for your system, then freeze it with package.*.mrsaccess wrote:I tried 2.6.2 on xorg-server 1.5.3-r2. Painful experience. I had to do an interactive boot in order to avoid xdm loading so I could get to a console and revert to the bad yet working at least in some ways 2.6.1.
Card X3100 (GM965 that is I think).
I did this once and had the right combo. Now I've lost it.
I agree with this in theory, but in practice, machines are different and run best with different versions and configurations. I would like to run the latest everything, but the reality of machines is, like with humans, requirements are different for different machines. Also, I speak from experience. The latest xorg and intel drivers just don't always run the fastest or smoothest on certain machines, no matter how you tweak it.rmh3093 wrote: going backwards never helps anything in the long run, make sure you have xorg 1.6, latest intel driver, and latest libdrm with matching kernel drm module, then go to #intel-gfx and talk to the devs to fix any regressions

im not saying use latest because its faster, im saying use latest because that is what is currently being worked on by the developers, if everyone used older versions then bugs and regressions like this would never be fixed because the people who discover them just go back to using what worked better in the past, the developers wouldnt release code it didnt pass tests on their own development boxesaudiodef wrote:I agree with this in theory, but in practice, machines are different and run best with different versions and configurations. I would like to run the latest everything, but the reality of machines is, like with humans, requirements are different for different machines. Also, I speak from experience. The latest xorg and intel drivers just don't always run the fastest or smoothest on certain machines, no matter how you tweak it.rmh3093 wrote: going backwards never helps anything in the long run, make sure you have xorg 1.6, latest intel driver, and latest libdrm with matching kernel drm module, then go to #intel-gfx and talk to the devs to fix any regressions
Having said that, I'm all for developers being receptive to input and trying to make their software work for as many machines as possible.
What is comes down to is "whatever works is right".
I just rebuilt one of my machines, and I'm going to side with you on this one. I'm using ~arch and I plan to try to get it working with the latest therefrom.rmh3093 wrote: im not saying use latest because its faster, im saying use latest because that is what is currently being worked on by the developers, if everyone used older versions then bugs and regressions like this would never be fixed because the people who discover them just go back to using what worked better in the past, the developers wouldnt release code it didnt pass tests on their own development boxes
Works fine for me. Same userspace, amd64.cruzki123 wrote:I have a working KMS laptop with 2.6.29-rc6, xorg-server-1.6, xf86-video-intel-2.6.2, but I don't have a fbconsole. I mean, I can switch fast to a fbconsole, but I only get a distorsion in the screen. When I sitch back to VT7 I have my screen right. Does anyone knows about it? I suspect of my kernel configuration.

szczerb wrote:Is this available in any overlay?0000000000000 wrote:anholt's drm-intel kernel
Code: Select all
git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
cd drm-intel
make menuconfig
etc...Code: Select all
Load "dri2"Code: Select all
Option "DRI2" "true"
Option "AccelMethod" "UXA"
Option "Tiling" "no"Code: Select all
One minor problem is that `xset dpms force off` doesn't work for some reason. Did anyone experience this? Solutions?