Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Hi there, I've just bought a new dell mini 12 and I can't get to make Xorg work with a descent resolution and accelerated graphics. After a few research online, it seems the PSB drivers are needed, both DRM and Xorg drivers. Could you guys work on xf86-video-psb and psb-kmd ebuilds? please.... it seems sources and firmwares can be found here: - http://v1.moblin.org/build-results/projects/psb-kmd/lpia/ - http://v1.moblin.org/build-results/projects/xf86-video-psb/lpia/ thanks for your reactivity julien Reproducible: Always
hi, it seems more up-to-date material can be found here: https://edge.launchpad.net/~ubuntu-mobile/+archive/ppa/+index?field.name_filter=psb&field.status_filter=published&field.series_filter=any it seems only ubuntu developpers (Ubuntu Mobile Team) are active on this piece of code now. actually, the laptop was shipped with Ubuntu and working 3D graphics. this might be the best starting point. julien
Hi there, I don't want to be pushy here but I would appreciate if this bug report could get a higher priority. After some chats on the forums, it turns out I'm far from being the only gentoo user with this laptop. such a notebook without even 2D acceleration is close to useless. this bug is actually blocking! distros like Ubuntu, Fedora and Mandriva already support this driver-set... please don't get offended by that post. I just want to use my favorite distro on my laptop :) good luck, julien
I'd be willing to proxy-maintain this, but since I don't have the hardware (nor am I willing to buy a GMA500 laptop, not in its current state), you'll have to come up with ebuilds. I will help you get them in shape, but this has to come from you interested folks. Thanks
Let's contact sunrise folks too. Thanks
if some of you guys write some functional ebuilds, I will test them right away and give feed back. also, I would advertise it with the people I found on the forums having the same graphic chipset. with the few tests I made on the sources, I can tell this would be no ordinary ebuild and that the x11 guys would be the best people to make it happen.
(In reply to comment #5) > if some of you guys write some functional ebuilds, I will test them right away > and give feed back. > also, I would advertise it with the people I found on the forums having the > same graphic chipset. To be perfectly honest, I have no interest whatsoever in Poulsbo. For me it's just another binary driver, one that sucks. A lot. The procedure here is to find a developer willing to write the ebuilds and maintain them (I doubt you'll find anyone) or you write the ebuilds and one of us (X devs) proxy-maintains for you. The latter option that means, you get to do most of the work and we just make sure your ebuilds are up to portage standards. As for me, I can't write ebuilds for applications I can't test. I have enough work with the rest of X11 as it is. If you do not know how to write ebuilds, head over to http://devmanual.gentoo.org/ to start learning, it's not as hard as it seems. :) Thanks
writing ebuilds in itself is not an issue. for the psb drivers however, it seems libdrm needs to be patched with some specific psb-compatible features and I doubt you guys would be happy if just a nobody came to touch it. the best I could so far was lobbying for its support. I have absolutely no free time to contribute. > To be perfectly honest, I have no interest whatsoever in Poulsbo. For me it's > just another binary driver, one that sucks. A lot. I guess that's clear enough. you have your opinion on that driver, good for you. the problem still is that several notebooks have that chipset and it's more likely that even more of them will in the future.
(In reply to comment #7) > for the psb drivers however, it seems libdrm needs to be patched with some > specific psb-compatible features and I doubt you guys would be happy if just a > nobody came to touch it. Indeed I wouldn't be happy, but you can post the patches here for review as well. We can then decide how to handle poulsbo-specific patches. > the best I could so far was lobbying for its support. I have absolutely no > free time to contribute. Then ask for contributions on the forums. I'm sure another Poulsbo owner can write the ebuild. I'll gladly help writing those ebuilds, but this has to start from one of you guys, since you are the ones with the hardware. > I guess that's clear enough. > you have your opinion on that driver, good for you. > the problem still is that several notebooks have that chipset and it's more > likely that even more of them will in the future. What I think about the poulsbo driver still doesn't change the fundamental issue. I am not going to write an ebuild for a driver I can't even test, nor will the X11 herd. I did say earlier that I was willing to proxy-maintain the driver. Again, feel free to send me ebuilds and patches, I _will_ review them and commit them if anyone steps up for proxy-maintenance. Or it can even live in the x11 overlay until bugs are sorted out. Thanks
thanks. I cannot promise anything but I'll try to find time to make things work out. if I come up with interesting stuff, I'll let you know. thanks again.
(In reply to comment #9) > thanks. I cannot promise anything but I'll try to find time to make things work > out. if I come up with interesting stuff, I'll let you know. thanks again. > I have time for testing, quite happy to help out but im no dev, I'll try to get some more intrest into this - dev wrangling :-)
I'm attaching a set of ebuilds that are a straightforward adaption of the work done by Adam Williamson [1]. This works perfectly for my Sony Vaio P11 giving me a native resolution for both framebuffer and X. (Sidenote: can anybody point me to a doc on how to get the gps module in this thing working?) Anyway, yes: 3D with direct rendering is working, giving me a mindblowing 180-200fps on glxgears. From what I read, the driver also supports Xrandr and VAAPI, intels new API for video acceleration. A patched version of mplayer to use that can also be found at [1]. The packages are: x11-drivers/psb-firmware - firmware for the chipset x11-drivers/psb-kmod - kernel modules. see notes below x11-libs/libdrm-poulsbo - hacked libdrm. to be installed alongside original one x11-libs/xpsb-glx - needed for 3D accelaration x11-drivers/xf86-video-psb - the actual xorg driver simply emerge xf86-video-psb and it will pull in everything else. some notes on the kernel modules: this driver needs its own version of the drm.ko module, meaning that CONFIG_DRM must be disabled in the kernel. The actual driver is the psb.ko module which also implementes a framebuffer. Two problems come with this: - the driver needs three kernel options that can not be directly selected but will be pulled in when needed by other drivers. These are CONFIG_{FILLRECT,COPYAREA,IMAGEBLIT}. To enable these options you can either hack the Kconfig file to make them visible or simply select a driver that pulls them in, for example VESAFB. - When the psb.ko module is loaded it will immediately switch to framebuffer console. This will give you a seriously messed up screen if you either have no support for framebuffer console (CONFIG_FRAMEBUFFER_CONSOLE) or already have another framebuffer console running. If you dont want a framebuffer at all, load the module with no_fb=1 as parameter. Apart from that, all seems fine. The module even gets automatically detected and loaded at boot. You will then have to adjust your xorg.conf manually with "psb" as driver. One more note: At least on my machine, X refuses to start with "cannot mmap framebuffer". This can be resolved by pretending to have less ram than you actually have. For me, mem=2039MB as kernel parameter works. [1] http://www.happyassassin.net/2009/05/13/native-poulsbo-gma-500-graphics-driver-for-fedora-10/
Created an attachment (id=203152) [details] poulsbo firmware
Created an attachment (id=203154) [details] psb kernel modules
Created an attachment (id=203155) [details] poulsbo version of libdrm
Created an attachment (id=203157) [details] poulsbo glx
Created an attachment (id=203158) [details] poulsbo xorg driver
Great work - i'll find some time today to test on my lil dell mini 10, be nice if one of the devs step forward and take this up as a maintainer seeing as all the hard work has been done. Will test then bug devs to get this in tree, it is BugDay today anyhow :D J
(In reply to comment #13) > Created an attachment (id=203154) [edit] [details] > psb kernel modules Please wrap pkg_config() at 80 columns/chars. (In reply to comment #16) > Created an attachment (id=203158) [edit] [details] > poulsbo xorg driver RDEPEND should have one atom per line. Other than that, the ebuilds look fine. I do suggest these packages go through sunrise first. Thanks
(In reply to comment #17) > Great work - i'll find some time today to test on my lil dell mini 10, be nice > if one of the devs step forward and take this up as a maintainer seeing as all > the hard work has been done. > Will test then bug devs to get this in tree, it is BugDay today anyhow :D > > J > I got lazy and dropped the ebuilds into my current local sunrise overlay - all came in fine and X worked right away after modprobing psb and changing Xorg.conf to use psb. Will test throughout the day. J
Had no issues since install, maybe the ebuild could be tarted up a little to me best practices but all in all this driver is stable. Someone to bump to tree?
So... Apart from the missing dependencies (xf86-video-* tends to depend on xorg-server and a few other bits :D ) the ebuilds are mostly working. Big issue is libdrm-poulsbo, which tries to overwrite large parts of libdrm. If you avoid the collisions you get nice failures because xf86-video-psb gets "bad" files. This sucks a lot :) And it means that with default settings (FEATURES="collision-protect") it's currently uninstallable. If anyone finds a clean workaround for that ... patches welcome. Until then No Go.
> Big issue is libdrm-poulsbo, which tries to overwrite large parts of libdrm. actually, libdrm-poulbo is meant to be installed completely into /usr/lib/psb and thus surely cannot overwrite any original libdrm stuff. If this happens for you anyway, something is worng. Either with the ebuild or your system. At least for me, the situation is as follows: #equery f libdrm-poulsbo * Searching for libdrm-poulsbo ... * Contents of x11-libs/libdrm-poulsbo-2.3.0_p9: /etc /etc/env.d /etc/env.d/02psb /usr /usr/include /usr/include/psb /usr/include/psb/drm /usr/include/psb/drm/drm.h /usr/include/psb/drm/drm_sarea.h /usr/include/psb/drm/i915_drm.h /usr/include/psb/drm/mach64_drm.h /usr/include/psb/drm/mga_drm.h /usr/include/psb/drm/nouveau_drm.h /usr/include/psb/drm/psb_drm.h /usr/include/psb/drm/psb_drv.h /usr/include/psb/drm/psb_reg.h /usr/include/psb/drm/psb_schedule.h /usr/include/psb/drm/r128_drm.h /usr/include/psb/drm/r300_reg.h /usr/include/psb/drm/radeon_drm.h /usr/include/psb/drm/savage_drm.h /usr/include/psb/drm/sis_drm.h /usr/include/psb/drm/via_3d_reg.h /usr/include/psb/drm/via_drm.h /usr/include/psb/xf86drm.h /usr/include/psb/xf86drmMode.h /usr/include/psb/xf86mm.h /usr/lib /usr/lib/pkgconfig /usr/lib/pkgconfig/libdrm-poulsbo.pc /usr/lib/psb /usr/lib/psb/libdrm.la /usr/lib/psb/libdrm.so -> libdrm.so.2.3.0 /usr/lib/psb/libdrm.so.2 -> libdrm.so.2.3.0 /usr/lib/psb/libdrm.so.2.3.0 /usr/lib/psb/pkgconfig This was done by the attached ebuilds and looks fine to me. Definitly no collisions here.
Using commit message: ------------------------------------------------------------------------------ Initial import of the intel poulsbo graphics driver and support libs. Fixes #274184. Thanks to Konrad Campowsky for the ebuilds and all the people who tested them. (Portage version: 2.2_rc40/cvs/Linux x86_64) ------------------------------------------------------------------------------ It took me some time to get the ebuilds into a mostly good shape. Still some rough corners, but for a first version that should be good enough. The libdrm failure was a naughty autotools issue :) Since I don't have the hardware I'll have to rely on your testing to find any issues. As far as I can tell the kernel module won't compile against 2.6.31 kernels ... @x11 herd: I haven't added you to metadata. I would appreciate it if you'd add yourself to that package.
xf86-video-psb won't compile. see my bug report: http://bugs.gentoo.org/show_bug.cgi?id=285274
(In reply to comment #23) > Using commit message: > ------------------------------------------------------------------------------ > Initial import of the intel poulsbo graphics driver and support libs. Fixes > #274184. Thanks to Konrad Campowsky for the ebuilds and all the people who > tested them. > (Portage version: 2.2_rc40/cvs/Linux x86_64) > ------------------------------------------------------------------------------ > > It took me some time to get the ebuilds into a mostly good shape. Still some > rough corners, but for a first version that should be good enough. > The libdrm failure was a naughty autotools issue :) > > Since I don't have the hardware I'll have to rely on your testing to find any > issues. As far as I can tell the kernel module won't compile against 2.6.31 > kernels ... > > @x11 herd: I haven't added you to metadata. I would appreciate it if you'd add > yourself to that package. > Patrick, I'm having the same problem when emerging libdrm-poulsbo, lots of package collisions with libdrm. How did you fix this issue? "A naughty autotools issue" is a bit vague to me :) Either way, nice work everyone on this driver! I've been wanting this for quite some time.
> I'm having the same problem when emerging libdrm-poulsbo, lots of package > collisions with libdrm. > How did you fix this issue? "A naughty autotools issue" is a bit vague to me It was depending on automake-1.9 iirc, and I had only 1.10 and 1.11 installed (or something very similar. I don't have eidetic memory :) ) Adding WANT_AUTOMAKE="1.9" to the ebuild made the autotools eclass do The Right Thing. If it fails for you I presume the eautoreconf call isn't run. Best thing to do is file a new bug with the whole build log and emerge --info and any extra info you think is relevant (better than spamming this closed bug)
(In reply to comment #27) > It was depending on automake-1.9 iirc, and I had only 1.10 and 1.11 installed > (or something very similar. I don't have eidetic memory :) ) > Adding WANT_AUTOMAKE="1.9" to the ebuild made the autotools eclass do The Right > Thing. If it fails for you I presume the eautoreconf call isn't run. > > Best thing to do is file a new bug with the whole build log and emerge --info > and any extra info you think is relevant (better than spamming this closed bug) > Adding that worked perfectly, thanks! Will post the next problem in #285274
