Question for Airlied:
I have been try to get KMS working on another distro (gentoo) but have so far been unsuccessful.
I've got the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git (drm-rawhide branch) built it with modesetting on by default all built fine, libdrm from git://git.freedesktop.org/git/mesa/drm.git (modesetting-gem branch) and xf86-video-ati from git://people.freedesktop.org/~airlied/xf86-video-ati (branch radeon-gem-cs). When I boot without nomodeset it will get to openrc and then load the modules where I get a blank screen and a no signal message on the screen. In the logs it pretty much just says that it can't find anything connected to the graphics card (r580 x1900 xt) and it says the drivers loaded fine. I also tried building drm and radeon into the kernel but the same happens just much earlier in the boot process.
Is there anything else I need to do/enable/install?
Any help is appreciated :)
The neat thing about Plymouth is that you should still get those messages. With RHGB I recall that if an error occurred, it immediately switched to the details mode that showed the console output. I believe with Plymouth it will show you all errors once GDM starts inside of a log window.
Again, if it's still just "alpha-grade" software, I can give them a break, but they're only hurting themselves and the development process by making their software difficult to use and experiment with.
Previews of upcoming software is nice and all, but it's much nicer if us Linux users can actually have access to it so we can try it for ourselves. Duh. I'm not saying anything that isn't completely obvious. I hope Plymoth will be available for Linux users to try in the future. Fxxx exclusive distro lock-in.
I am one of the HUGEST proponents of the "Linux needs to make software installation not suck donkey balls" movement that thinks the appliance-nature of current distros software models is essentially useless for real users. I willing to be that I've written more artiles (a.k.a. rants) on the topic than anyone else.
But that has nothing to do with Plymouth. Plymouth is not an application you install. It is a core part of the distribution that must be integrated at a software level. It requires code modifications to work. It requires patched applications. It requires a ton of changes that must be done at the source level, and those changes are to components that are customized for each distribution.
It IS NOT AN APPLICATION for you to install. You might as well claim that Windows' SVCHOST is broken because it can't be installed/uninstalled just like any other application.
If you want Plymouth that badly, go ahead and integrate it with your distro, and send the patches upstream. I'm sure they'll love it. It's just in any way even remotely technically feasible to make a package that can magically install it, modify your initrd, modify your initscripts, patch your GDM and xorg packages, patch your kernel, and modify your grub and early bootup config files. This is just something that sits at the lowest levels of the OS, below the components that are expected to be user manageable.
I'm not telling you how things are. For all I know, all this integration isn't smooth and modular and the communication isn't nailed down yet, so heavy modification to get Plymouth running, like you said, may very well be what is required right now, OK I accept that.
I'm telling you how things should be, and I think you'd agree. So, we're done there then. :) I hope these programs all mature more and/or become more standardized or gain standardized interfaces or whatever it takes so that the whole system is easier to tweak and will allow for an easier time of installing things like Plymouth in the future.
Those are problems that I would be working on first if I were working on the Plymouth project, are ways for it to play nicely with other software so that users could easily install it. I wouldn't even begin programming until I could work out a nice modular system for installation and communication/integration with everything else. Then, I would use those APIs or whatever me and whoever else came up with when I made my program, or I'd make my program compatible with those APIs after-the-fact.
Plymouth _does_ use an API to communicate with components. But the simple fact is that those components have to be modified to use that API, because there was no such API before.
And you still have to deal with components needing patches. In order for Plymouth to work the way it does, X needs to not change mode on startup, or blank the pixmap, or so on. Once those patches are upstream and all distributions are already shipping versions of those packages with those patches, then sure, Plymouth would be easier to just install as a package, but you're still going to have to deal with differences like the initrds, or even the package management system itself.
Installation of software needs to be easier, yes. But not for things like Plymouth. It's not something that should _need_ installing, as it's something that should just be built into your distribution. Things like that don't need easy installation, and don't make sense to even advertise to users as components they can install or uninstall. It's a little irritating at first because your distribution doesn't ship Plymouth, perhaps, but that's unavoidable. Distributions like Fedora exist almost solely for the purpose of being test beds for software like this, while distributions like Debian or SUSE try to be conservative. If you want to use bleeding edge low-level OS components, use an OS that was intended for that purpose, not one that's meant to be stable and reliable.
Well I finally got KMS working on gentoo. I had to get a src rpm kernel from fedora then compile it as the sources in airlied's git repo mustn't have been sufficient.
If anyone else wants to try KMS out on gentoo:
- Get the x11 overlay with layman (layman -a x11)
- Take the -9999 (git) ebuilds for libdrm, mesa and xf86-video-ati
- Delete the x11 overlay if you want (layman -d x11)
- Modify the ebuilds by putting the line EGIT_BRANCH="<branch>" BEFORE the inherit line.
- Change EGIT_REPO_URI="<whatever>" to the URIs in my above post and match them with the branch
- Put these ebuilds in your overlay and merge!
BTW - I can't compile the r300-buffmgr branch of mesa so it might be worth trying r300-bufmgr-fedora
- To get the kernel got to koji.fedoraproject.org search for kernel, get the latest src.rpm
- Now, you can either use rpm2targz and apply the patches on by one...
Or you can `emerge rpm` and then follow the guide at > http://fedoraproject.org/wiki/Docs/CustomKernel < use only the parts that are applicable.
Hope this helps some other people.
Edit: It's still not working as it should. I'd say it only works about 1 out of 3 boots but I don't know why as there is nothing different in the failed logs than the successful logs. Any ideas?
Edit2: Working fine now, I have 3D to a degree... I can run glxgears but not kwin4 compositing but I suspect this is because I can't compile the mesa branch.
Edit3: Managed to compile the mesa branch. It turns out there was a problem with my dri2proto. So, now I have kwin compositing and KMS!!
Sooo.. This really looks quite cool. However, this was already possible with bootsplash, including the animations. Can someone fill me in on what is special?
It uses KMS to get less flicker, and shows the pic later than bootsplash, and probably uses some amounts of ram and so does not run on machines older than variable Y. But what else?