xf86-video-intel-2.15.0 [Re: [qubes-devel] video support of qubes beta 2 on thinkpad x220]
Stefan Boresch
following up on the xorg issues which presumably affect currently all sandybridge based machines using the on chip graphics, I did some fooling around:
Note: I have no spare sandybridge machine, so this is a little roundabout, and the actual test on qubes is missing. However, I'd appreciate advice before potentially hosing my qubes installation anyways.
I installed vanilla Fedora 13 on an old spare machine (intel i915 graphics), installed all FC13 updates, then upgraded to the dom0 kernel of qubes beta 2 (plus all packages (xen,qemu) that were required to make rpm happy. The xorg-x11-drv-intel version is 2.11, as in qubes beta 2. I then set out to build an xorg-x11-drv-intel
rpm based on xf86-video-intel-2.14, which would correspond to the one provided in FC15. The FC15 live CD boots and runs my x220 fine; also, from everything else I read 2.14 should be the first codebase supporting sandybridge. Aside from installing all sorts of build requirements (all installed from vanilla FC13), I had to
(1) upgrade libdrm. For that I rebuilt the libdrm rpm coming with FC15 (2.4.25); to my pleasant surprise this worked with rpmbuild --rebuild.
(2) However, a rebuild of xorg-x11-drv-intel-2.14.0-6.fc15.src.rpm failed (as far as I can tell because of some patches applied to the vanilla 2.14 source). Thus, I took the spec file of this rpm and used it to build a rpm based on the xf86-video-intel-2.15.0 source. None of the patches that are applied in the 2.14 rpm were applied. This builds without a hitch, installs (yum refuses because my rpm isn't signed, but rpm installs happily), and boots me in a working desktop (on my non-sandybridge test machine). I verified the use of the intel module 2.15 in Xorg.0.log
To sum up, at this point I have a FC13 dom0 on the qubes hypervisor using xf86-video-intel-2.15.0 (in RH/Fedora speak: xorg-x11-drv-intel-2.15.0), which should support sandybridge graphics. My x220 with qubes beta 2 is at home, but I am wondering how safe/sane it is to just install these two rpms in the dom0 of qubes.
Some of my worries are:
(1) My exercise is/was mute, if the kernel modules are not recent enough, but I guess this I just have to test.
(2) I'll certainly get complaints, since my rpms are not signed.
(3) Most importantly, is my basic assumption that an rpm built on FC13 should work in the qubes dom0 correct?
More generally, since my rpm/yum skills are non-existent (aside from qubes I have only used debian based OSes for the last 7 years or so), I am wondering whether what I do makes any sense. Also, the present approach will only cover basic 2D support, clearly more packages would need to be updated for 3D support ..
Hints, comments, suggestions welcome!
Stefan
Joanna Rutkowska
It all does seem to make sense (assuming our Dom0 kernel really support
Sandy Bridge GPU, which I think seems likely). So, will you be able to
actually test it on your SB Qubes laptop? If not, perhaps you could sign
your RPMs and upload them somewhere and some other people from the list,
who have Sandy Bridge laptops, could test them?
Thanks,
joanna.
Joanna Rutkowska
Stefan Boresch
On 10/27/11 14:59, Stefan Boresch wrote:
[snip]
It all does seem to make sense (assuming our Dom0 kernel really support> Hints, comments, suggestions welcome!
>
Sandy Bridge GPU, which I think seems likely). So, will you be able to
actually test it on your SB Qubes laptop? If not, perhaps you could sign
your RPMs and upload them somewhere and some other people from the list,
who have Sandy Bridge laptops, could test them?
thanks for the feedback. Given that I am happy to test (and won't blame anyone if something goes wrong!). I'll report back tomorrow and will also upload what I have.
Best regards,
Stefan
Joanna Rutkowska
http://intellinuxgraphics.org/2011Q1.html
Of course there is no signature, right? ;)
j.
Stefan Boresch
Just to double check: you got intel driver from this page:
http://intellinuxgraphics.org/2011Q1.html
Of course there is no signature, right? ;)
j.
Stefan
Joanna Rutkowska
> 2011/10/27 Joanna Rutkowska <joa...@invisiblethingslab.com>
>
>>
>> Just to double check: you got intel driver from this page:
>> http://intellinuxgraphics.org/2011Q1.html
>>
>> Of course there is no signature, right? ;)
>>
>> j.
>>
>>
> Yes, and, yes, now that you mention it I don't seem to be able to find a
> signature.
Hehe... I will ping them about this.
> [However, by 'not signed' I meant that my self-built rpms
> (rpmbuild --rebuild, rpm -ba) cause yum to complain about not being signed
> ..]
>
joanna.
Stefan Boresch
I am pleased to report that I am now happily running X using the 'intel' device driver, following the steps outlined in the first post in this thread. The driver sets the screen size correctly (no xorg.conf stubs necessary), and 2D accel is working. The desktop feels a lot snappier, scrolling a browser window is now possible and the 'usual' speed. I attach output from my xorg.0.log.
Please find SRPMs under http://www.mdy.univie.ac.at/de/people/boresch/privat/qubes/
The key to sign the rpms was made ad-hoc and is not on any keyserver; for the record, it's fingerprint is:
gpg> fpr
pub 4096R/2E4DC2E3 2011-10-27 Stefan Boresch (rpm signing key) <sbor...@gmail.com>
Primary key fingerprint: A741 A75F CD35 2204 280D 1D9F F7C7 E291 2E4D C2E3
The signing of the rpm is fairly meaningless given that at present the source cannot
be verified. Again, for the record: libdrm is a simple rpmbuild --rebuild of the vanilla FC15 package. The xorg-x11-drv-intel package started from the .spec file of the corresponding
FC15 package, but replacing the 2.14 source with the 2.15 source from http://intellinuxgraphics.org/2011Q1.html, and not applying any patches.
Question concerning further work: As expected, 3D is not working; glxinfo
fails with:
Unrecognized deviceID 126
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 21
Current serial number in output stream: 24
name of display: :0.0
Also, it seems further stuff needs to be compiled for some additional acceleration features (see http://intellinuxgraphics.org/build.html). I may continue to fool around a bit; the question is which of the potential features make sense in the context of qubes. (I guess none of us installed it to play 3D shooters ;-) I admit that the range of acceleration options confuses me -- on my regular work machines I am stuck for better or worse with the proprietary nvidia drivers (GPU programming, run CUDA applications), and there most of the time things work out of the box.
Best regards,
Stefan
Joanna Rutkowska
> Hi,
>
> I am pleased to report that I am now happily running X using the 'intel'
> device driver, following the steps outlined in the first post in this
> thread. The driver sets the screen size correctly (no xorg.conf stubs
> necessary), and 2D accel is working. The desktop feels a lot snappier,
> scrolling a browser window is now possible and the 'usual' speed. I attach
> output from my xorg.0.log.
>
> Please find SRPMs under
> http://www.mdy.univie.ac.at/de/people/boresch/privat/qubes/
>
Thanks a lot! I think this represents the most valuable "community"
contribution to the Qubes project yet :) Hopefully more people will
contribute now.
/.../
> Question concerning further work: As expected, 3D is not working; glxinfo
> fails with:
>
> Unrecognized deviceID 126
> X Error of failed request: BadAlloc (insufficient resources for operation)
> Major opcode of failed request: 153 (GLX)
> Minor opcode of failed request: 3 (X_GLXCreateContext)
> Serial number of failed request: 21
> Current serial number in output stream: 24
> name of display: :0.0
>
Can you see if some of the desktop effects under KDE work fine? Such as
e.g. the "grid" and "present windows" effects? (surely the "cube" effect
won't work without 3D, but the other ones should, and they are much more
useful IMO).
> Also, it seems further stuff needs to be compiled for some additional
> acceleration features (see http://intellinuxgraphics.org/build.html). I may
> continue to fool around a bit; the question is which of the potential
> features make sense in the context of qubes. (I guess none of us installed
> it to play 3D shooters ;-)
The only thing currently (i.e. when we do not expose GPU to VMs) are
desktop effects IMO.
> I admit that the range of acceleration options
> confuses me -- on my regular work machines I am stuck for better or worse
> with the proprietary nvidia drivers (GPU programming, run CUDA
> applications), and there most of the time things work out of the box.
>
Exposing CUDA/OpenCL to VMs might be even more tricky than exposing
OpenGL... Surely not coming in Qubes 1.0. Sorry :/
Thanks,
joanna.
Stefan Boresch
On 10/28/11 09:29, Stefan Boresch wrote:Thanks a lot! I think this represents the most valuable "community"
contribution to the Qubes project yet :) Hopefully more people will
contribute now.
You are welcome!
Can you see if some of the desktop effects under KDE work fine? Such as
e.g. the "grid" and "present windows" effects? (surely the "cube" effect
won't work without 3D, but the other ones should, and they are much more
useful IMO).
They don't seem to be working .. when I have time I'll poke a bit deeper.
The only thing currently (i.e. when we do not expose GPU to VMs) are
desktop effects IMO.
OK, which narrows down the task list; i.e., get glxgears to run (in dom0, installed it is)
Exposing CUDA/OpenCL to VMs might be even more tricky than exposing
OpenGL... Surely not coming in Qubes 1.0. Sorry :/
I wouldn't even expect it even for 2.0 ..
Best regards,
Stefan
Stefan Boresch
Hi,
2011/10/28 Joanna Rutkowska <joa...@invisiblethingslab.com>On 10/28/11 09:29, Stefan Boresch wrote:
Can you see if some of the desktop effects under KDE work fine? Such ase.g. the "grid" and "present windows" effects? (surely the "cube" effect
won't work without 3D, but the other ones should, and they are much more
useful IMO).
They don't seem to be working .. when I have time I'll poke a bit deeper.
http://www.mdy.univie.ac.at/de/people/boresch/privat/qubes/
Note: In terms of binaries, you need to install: mesa-libGL, mesa-libGLU, mesa-dri-filesystem (*), mesa-dri-drivers, mesa-dri-llvmcore (*). The (*) packages don't even exist in FC13.
For the purposes of qubes, I don't think there is the need to build libva (there isn't even an
official FC15 package yet). By contrast, if the next qubes (release or beta3) has an even newer kernel, one might try to rebuild/backport the FC16 packages (sandybridge graphics seems still to undergo active development).
Best regards,
Stefan
Joanna Rutkowska
> Hi,
>
> 2011/10/28 Stefan Boresch <sbor...@gmail.com>
>
>>
>>
>> 2011/10/28 Joanna Rutkowska <joa...@invisiblethingslab.com>
>>
>>> On 10/28/11 09:29, Stefan Boresch wrote:
>>>
>>> Can you see if some of the desktop effects under KDE work fine? Such as
>>>
>> e.g. the "grid" and "present windows" effects? (surely the "cube" effect
>>> won't work without 3D, but the other ones should, and they are much more
>>> useful IMO).
>>>
>>>
>> They don't seem to be working .. when I have time I'll poke a bit deeper.
>>
>>
> turns out that a straigtforward rebuild of the FC15 mesa package in my FC13
> build environment produces usable RPMs and, voila, dom0 3D support has
> arrived; in particular, desktop effects are now working. For the SRPM see
>
> http://www.mdy.univie.ac.at/de/people/boresch/privat/qubes/
>
Where did you get the libdrm 2.4.25 SRPM? Did you create it yourself?
> Note: In terms of binaries, you need to install: mesa-libGL, mesa-libGLU,
> mesa-dri-filesystem (*), mesa-dri-drivers, mesa-dri-llvmcore (*). The (*)
> packages don't even exist in FC13.
You mean the non-asterisked packages can be obtained from F13 updates
repo, while the asterisked ones from (your?) mesa-7.11 SRPM?
joanna.
Stefan Boresch
2011/11/8 Joanna Rutkowska <joa...@invisiblethingslab.com>:
> On 10/31/11 09:52, Stefan Boresch wrote:
> Where did you get the libdrm 2.4.25 SRPM? Did you create it yourself?
>
No, I took the libdrm 2.4.25 SRPM of FC 15, installed it (on my plain
FC 13) build host, and executed
rpmbuild -ba libdrm.spec (+ signing it with my key).
So this is why the resulting SRPM has fc13 in the name. Doing the
rebuild seemed cleaner to me than just trying to force the fc15 binary
down the throat of my system.
>> Note: In terms of binaries, you need to install: mesa-libGL, mesa-libGLU,
>> mesa-dri-filesystem (*), mesa-dri-drivers, mesa-dri-llvmcore (*). The (*)
>> packages don't even exist in FC13.
>
> You mean the non-asterisked packages can be obtained from F13 updates
> repo, while the asterisked ones from (your?) mesa-7.11 SRPM?
>
I followed the same procedure just outlined for libdrm for the mesa
package(s). What I tried to indicate with the stars (*) is that the
single SRPM builds multiple RPMs, some of which have no counterpart in
FC13. This confused me initially: When I wanted to use the RPMs I had
just built to upgrade the original FC13 RPMs, I got dependency errors
(and neither the yum, nor the rpm messages were too clear).
Eventually, I realized that the rebuild of the FC15 mesa-srpm had
'created' a few 'additional' rpms. So these starred rpms need to be
included when trying to upgrade (i.e., they are new installs). Again,
maybe one can/could/should install/upgrade to just the existing FC15
mesa RPMs.
Sorry for not being clear earlier,
Stefan
Danny Fullerton
I'm having the same problem. Well, maybe my X env skills aren't that good either.
--
Danny Fullerton
Stefan Boresch
2011/11/10 Joanna Rutkowska <joa...@invisiblethingslab.com>:
> On 11/08/11 22:23, Stefan Boresch wrote:
> So, where did you get the mesa-dri-llvmcore? It doesn't seem to be
> produced by building of neither of the SRPMs you mentioned...?
>
I am confused. Are you getting errors? What is happening in your build
environment?
Below are my steps and checks I just redid, but the short answer is
that I 'just get' this rpm ..
On my 'build' host (vanilla FC 13, yum updated)
rpmbuild --rebuild mesa-7.11-0.9.20110509.0.fc15.src.rpm
builds:
# ls rpmbuild/RPMS/x86_64/mesa-*
rpmbuild/RPMS/x86_64/mesa-debuginfo-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-dri-drivers-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-dri-drivers-dri1-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-dri-filesystem-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-dri-llvmcore-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libEGL-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libEGL-devel-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGL-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGL-devel-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGLES-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGLES-devel-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGLU-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libGLU-devel-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libOSMesa-7.11-0.9.20110509.0.fc13.x86_64.rpm
rpmbuild/RPMS/x86_64/mesa-libOSMesa-devel-7.11-0.9.20110509.0.fc13.x86_64.rpm
Concerning mesa-dri-llvmcore, this is what should happen according to
the spec file
(the respective sections are protected by some %if, but on the top of
the spec 'with_llvmcore' is set to 1).
Note that when first building I had to satisfy some build
dependencies, so on my system I have
llvm-libs-2.8-10.fc13.x86_64
llvm-2.8-10.fc13.x86_64
installed, and I believe I installed temporarily the llvm-static
package which seems to be a build
requirement. Interestingly, these llvm rpms are only in the FC13
*update* repository
(there are no llvm rpms in the plain FC13 repo); in any case it's
nothing I built.
So, I just ran first through a rebuild from the original FC15 SRPM and
things behave as described.
Then, I copied the "FC13" SRPM just created and wiped all mesa stuff
from my rpmbuild directory,
reinstalled the "FC13" SRPM and did
rpmbuild -sign -ba mesa.spec
The same RPMS are built. I am happy to test / try things, but as I
said I am mostly confused
at this point.
Best regards,
Stefan