If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I have ubuntu 12.10 x64, how to compile and install newest version of xf86-video-intel ? I want see, if there is any bugs fixed, but i cant remember, how to compile it and install it, its not that simple like "configure, make and make install", it needs some things to be installed and so on. I saw that tutorial maybe a year ago, but now i cant find it and i dont remember it, so can anybody give me simple instructions how to do it ?

Google X.org updates repo.

It is official repository for tracking x.org related packages that will land in next Ubuntu. If newest intel is not there yet, than look for "xedgers" on launchpad, that keep track of newes of newest. Ofc. both of those can beark you computer, kill your kitties, etc. No instructions as its very important to follow official instructions, from respecive websites!

Leave a comment:

Leave a comment:

I have ubuntu 12.10 x64, how to compile and install newest version of xf86-video-intel ? I want see, if there is any bugs fixed, but i cant remember, how to compile it and install it, its not that simple like "configure, make and make install", it needs some things to be installed and so on. I saw that tutorial maybe a year ago, but now i cant find it and i dont remember it, so can anybody give me simple instructions how to do it ?

Leave a comment:

The DDX first calls drmCheckModesettingSupported() on its device fd. However, one bug reporter managed to get past that and still have X bail out as he had misbuilt his initramfs. So I added an extra check to make sure that we could query the outputs on the device fd before claiming the slot. So instead of generating an error later when KMS didn't work, we could simply allow X to use the next available driver (VESA/fbdev).

Thanks ickle. And good work

Leave a comment:

The DDX first calls drmCheckModesettingSupported() on its device fd. However, one bug reporter managed to get past that and still have X bail out as he had misbuilt his initramfs. So I added an extra check to make sure that we could query the outputs on the device fd before claiming the slot. So instead of generating an error later when KMS didn't work, we could simply allow X to use the next available driver (VESA/fbdev).

Good work!

Leave a comment:

Can somebody from Intel (kayden maybe?) tell me why "Double checking device has KMS support before claiming it" is needed...? Hardware would be static, so if you check it now or if you check it 10minutes from now...whether or not it has KMS support shouldn't change so why bother double-checking it?

s/double check/implement a much more accurate check/

The DDX first calls drmCheckModesettingSupported() on its device fd. However, one bug reporter managed to get past that and still have X bail out as he had misbuilt his initramfs. So I added an extra check to make sure that we could query the outputs on the device fd before claiming the slot. So instead of generating an error later when KMS didn't work, we could simply allow X to use the next available driver (VESA/fbdev).

Leave a comment:

Can somebody from Intel (kayden maybe?) tell me why "Double checking device has KMS support before claiming it" is needed...? Hardware would be static, so if you check it now or if you check it 10minutes from now...whether or not it has KMS support shouldn't change so why bother double-checking it?

Alternatively: 1 is static. If I do

if(1==1)
return true
else
return false

now, or 10 minutes from now... it should always return true. If it returns false, then we've broken the universe, which while MUCH more interesting, is wrong.