FreeBSD Foundation's New Project: Implement GEM/KMS/DRI for Intel Graphics

Status
Not open for further replies.
Do not update the source tree!

ashleyd said:
I believe that as long as you don't touch your source or update it you will not have to apply the patch again, even if you rebuild your kernel. If you cvsup your /usr/src to update it then I assume you will need to apply the patch again.

I am running xorgmerge again every time I upgrade my ports just to be safe, it only takes 1 second.
Click to expand...


Thanks ashleyd, unlucky I've updated the source tree, so the above patches cannot be applied anymore... I'm looking for a solution (and waiting for a new patch set for STABLE).
 
Hi,

Finally, this enterprise is a success, I am a happy guy :).

Below is the exact receipe I've followed while remaining within 9_STABLE:

step0: install FreeBSD 9.0 STABLE, using the i386 DVD image and my favorite text editor.

step1: update the ports tree

[CMD=""]portsnap fetch extract[/CMD]

step2: install required ports to get things done

Code: 
cd /usr/ports/ports-mgmt/portmaster
make install clean
cd /usr/ports/devel/subversion
make install clean

(reboot)

step3: update ports and complete source code
portmaster -a
csup cvsup0.txt

where

cvsup0.txt
Code: 
*default host=cvsup.FreeBSD.org
*default prefix=/usr
*default base=/var/db
*default release=cvs tag=RELENG_9
*default delete use-rel-suffix compress

src-all

step4: edit i915_suspend.c so that "$FreeBSD: blah[...]blah$" becomes "$FreeBSD$"

sed -i -e 's/FreeBSD: src.*Exp /FreeBSD/' /usr/src/sys/dev/drm/i915_suspend.c

step5: get and apply patch apply patch from /root


fetch [url]http://tsatsenko.ru/files/all.13.7-stable-9.patch[/url]
patch [b]-d[/b] /usr/src </root/all.13.1-stable-9.patch

check that there are no reject file!! otherwise reapply patch on clean source again and again:
find / -name "*.rej"

step6: recompile kernel
under /usr/src:
make buildworld && make buildkernel && make installkernel

(reboot)

make installworld

(reboot)

step7: add to /etc/make.conf the following lines:

Code: 
WITH_NEW_XORG="YES"
WITH_KMS="YES"

step8: install xorg

cd /usr/ports/x11/xorg
make install clean

(reboot)

step9: check out new version of Xorg and download the xorgmerge script.

svn co [url]https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2[/url]
fetch [url]http://people.freebsd.org/~miwi/xorg/xorgmerge[/url]
The svn check-outleads to have /root/xorg_7_5_2, hence edit the xorgmerge script with:
KDEDIR="/root/xorg_7_5_2"
then exec merge script:
sh xorgmerge

step10: rebuild xf86-* ports

portmaster -Raf (actually this rebuild everything)
 
I haven't found any indication that this is slated for 9.1-RELEASE. The man that's porting these features to the kernel and porting the new Intel driver over is still working on it. This isn't even considered a "testing" release yet. The most I can gather is it'll be done when it's done, and it seems like people in the community expect it to land in FreeBSD 10, although 9.x is certainly a possibility.
 
router54g said:
I haven't found any indication that this is slated for 9.1-RELEASE. The man that's porting these features to the kernel and porting the new Intel driver over is still working on it. This isn't even considered a "testing" release yet. The most I can gather is it'll be done when it's done, and it seems like people in the community expect it to land in FreeBSD 10, although 9.x is certainly a possibility.
Click to expand...

/me patiently waits =)
 
Hi, I have tried first to update the source tree to 9-STABLE with cvsup using RELENG_9 and applied the patch. Don't remember having checked for *.rej, but there might have been, because the compilation didn't work. Tried then to update to 10-CURRENT without reading here with the necessary attention. Now I have a 10-CURRENT installed. Is there a resonably easy way to implement a patch to this? Does the author has a home page or somewhere where we can check? I think it would be also important, because the 9-STABLE (RELENG_9) is a live source code and after some days the patch would not fit anymore anyway. It would be a better idea to have a patch to a RELEASE.

Is it possible for someone to do this? If someone has the correct stable and has had success applying the patch it is possible to download the 9.0-RELEASE source and generate a new patch to this, isn't it? Otherwise I see only the PC-BSD possibility now...

Cheers, Cartola.
 
cartola said:
Hi, I have tried first to update the source tree to 9-STABLE with cvsup using RELENG_9 and applied the patch. Don't remember having checked for *.rej, but there might have been, because the compilation didn't work. Tried then to update to 10-CURRENT without reading here with the necessary attention. Now I have a 10-CURRENT installed. Is there a resonably easy way to implement a patch to this? Does the author has a home page or somewhere where we can check? I think it would be also important, because the 9-STABLE (RELENG_9) is a live source code and after some days the patch would not fit anymore anyway. It would be a better idea to have a patch to a RELEASE.

Is it possible for someone to do this? If someone has the correct stable and has had success applying the patch it is possible to download the 9.0-RELEASE source and generate a new patch to this, isn't it? Otherwise I see only the PC-BSD possibility now...

Cheers, Cartola.
Click to expand...

Take a look at http://miwi.bsdcrew.de/2012/02/cft-xorg-upgrade-7-5-2/

I was running 9-RELEASE, updated my source to 9-STABLE, grabbed the latest 9-STABLE patch from http://tsatsenko.ru/files/ followed Toto's steps outlined in this thread and everything works great. If your kernel build is failing during compilation, rm /usr/src, rm /usr/obj, grab the sources again, apply the patch (edit i915_suspend.c first) rebuild world and kernel. It should work fine.
 
alie said:
How to load it if its live session?
Click to expand...

use the command # kldload drm.

additionally, add the line
Code: 
drm_load="YES"
to /boot/loader.conf to have this module loaded when the machine boots.
 
Since your hardware (hp2560p?) is not much different from what most of the people have here (including me), there is not magic or bad luck, my feeling is that you have a problem of method, you must be doing something wrong or working on some wrong assumptions; you may review things carefully.

Whether one chooses to follow the 10_CURRENT path of the 9_STABLE one, there should be enough materials developed here to get it right (that's only the humble opinion of a 1 month-old newbie).
 
Hi guys, Hello Toto,

I have an optimus laptop with i915 card + nvidia GT520M. I followed your steps, everything works fine regarding the kms activation process, but unfortunatelly, when the X is initialized, a lot of artifacts (random pixels) are shown in the top part of the screen. Also, the mouse clicks doesn't have any impact (the wm menu is not activated when I press left or right button - I use twm, fvwm2 or fluxbox - no menu with left/right/middle click).

So we talking about 2 problems:

1. artifacts present on the top of the screen
2. mouse clicks doesn't work

Technical notes:
- I used http://tsatsenko.ru/files/all.13.5-stable-9.patch (the newest patch from 04-Mar-2012 17:17) because I didn't find the patch 13.1 on the tsatsenko website
- I didn't found any *.rej files after aplying the patch so it seems I'm ok on that side
- The console switch (ctrl+alt+f2) seems to work for me, but when I quit the X (of course, by killing it, because the mouse buttons doesn't work), when I try to startx again, the X initialization fails with some drm initialization errors (this behavior is quite normal in my opinion, as long as kms support is in a pre-alpha stage).

And one more question: if I want to try another patch, not the newest one, do I need to rebuild the X again or to build the world will be enough?

Thank you very much, Toto, your tutorial was very helpful for me :)
 
Hi,

Just to be clear: I'm new at FreeBSD and I don't consider myself experienced enough to give sound advices. What prevail is common sense make and careful reviewing.

Getting back to your points:

- why a pre-alpha version of this driver meant to be working on intel nominally would ever have a chance to work on nvidia ? By default, you are lucky to only have pixel flickering...and forget about any ctrl+alt+fn combination (which is not even supposed to work with intel cards).

- As for your mouse problem: posting:Configuring X - read before you ask questions!

- I've tried 13.1 and 13.5 without noticing much difference. My desktop way of working (time spent/application used) doesn't pretend to be exhaustive enough to stress out any relevant difference.


Happy BSD-unixing !
 
ahavatar said:
Does this mean that after FreeBSD 9.1-RELEASE, the Intel Sandy-Bridge GPU just works out of box?
Click to expand...

This is copied out of the PC-BSD handbook:

http://wiki.pcbsd.org/index.php/PC-BSD_Users_Handbook

2.4.2 Laptops with Built-In Intel Video Chip
The FreeBSD Foundation and iXsystems are funding a project to add native DRI, GEM, and KMS support to the
FreeBSD kernel for version 9.1. In the mean time, video drivers that require these kernel hooks currently use the
X.org driver with those features disabled. Usually this means that the card works but may be missing features
such as 3D acceleration.
Click to expand...

So it is looking good!
 
Toto said:
Hi,

Just to be clear: I'm new at FreeBSD and I don't consider myself experienced enough to give sound advices. What prevail is common sense make and careful reviewing.

Getting back to your points:

- why a pre-alpha version of this driver meant to be working on intel nominally would ever have a chance to work on nvidia ? By default, you are lucky to only have pixel flickering...and forget about any ctrl+alt+fn combination (which is not even supposed to work with intel cards).

- As for your mouse problem: posting:Configuring X - read before you ask questions!

- I've tried 13.1 and 13.5 without noticing much difference. My desktop way of working (time spent/application used) doesn't pretend to be exhaustive enough to stress out any relevant difference.


Happy BSD-unixing !
Click to expand...

Yes, I'm a n00b regarding the Unix operating systems but I'm a game programmer for about 10 years so everyday I play with compilers/debuggers/openGL/directX/iOS SDK/Xbox dev kit and so on. In my world (yes, is a win or mac world), a patch means a patch - so as far as I know, a patch is a peace of code, not a peace of s**t. And I said that because I tried for several times to apply that bloody patch for drm from http://people.freebsd.org/~kib/drm/ (on src9 version or src10 head version) and I found a lot of *.rej files. What kind of patch is this if it doesn't feet even with the newest source code?

The problem is that some guys said the KMS patch works fine for them. Then a lot of people said "nooo, this code is only in an alpha stage and you should be happy to have artifacts on the screen, to have random crashes and so on".

Unfortunately, my laptop doesn't have a BIOS switch from Intel to NVidia card and the NVidia native driver doesn't work. That's why I try to configure somehow my videocard in FreeBSD. In fact, my plan is to make free casual games for FreeBSD - that's why I need to have 3D acceleration on my laptop.

Also, I already had hal and dbus (+gnome) enabled when I asked for help. I still don't know why the mouse clicks doesn't work.
 
akregator said:
http://tsatsenko.ru/files/ You should use these patch for src9 RELEASE and STABLE. For src10, I think it's normal because it is a development branch and it moves several times a day. What are these .rej files ?
Click to expand...

I didn't find any *.rej files using the tsatsenko's patches (I used 13.5 and 13.6 patches) applied on src9 (my frustration was releated to src10 + http://people.freebsd.org/~kib/drm/ patches). With tsatsenko's patches everything was compiled fine, I have KMS support, but as I said in a previous post, I found two big problems:

- screen artifacts (random pixels) appears at the top of the screen (fvwm, twm, even XFce starts, but a lot of random flickering pixels are present in the top part of the screen)
- the mouse clicks doesn't have any impact (again, YES, I have hald/dbus/gnome support enabled).

A note: keyboard works, but when I press, let's say (ALT+F2 - to open run app dialog in XFce), the screen artifacts change their position (random pixels are moving but only on 1/3 part of the screen - the top one).

So I think the problem is regarding the pixel buffer blitting from memory to the screen (maybe the video card pixel buffer address is wrong obtained or is malformed somehow). I should throw an eye on the .c files to see how the kernel works with drm and how these addreses are obtained - but I didn't have any experience regarding the FreeBSD kernel; actually, I'm new to the BSD world, but I like this OS and I consider it a great opportunity for me to contrib with some casual free games.

Thanks for help!
 
Status
Not open for further replies.
Back
Top