ports/156405: x11-drivers/xf86-video-ati driver: no hardware rendering

[Matthew Rezny]

On Wed, 28 Aug 2013 22:31:42 -0700
Kevin Oberman <rkoberman at gmail.com> wrote:

> On Wed, Aug 28, 2013 at 5:26 PM, Thomas Mueller
> <mueller6724 at bellsouth.net>wrote:
> 
> >
> > From my previous post and Niclas Zeising's response:
> >
> > > > I had this type of problem with NetBSD 5.1_STABLE and 5.99.x
> > > > even with
> > native X that is part of the base system, as opposed to pkgsrc X.
> > > I can't comment on how NetBSD does things, since I haven't used
> > > it.
> >
> > You aren't missing anything, judging from my experience.  FreeBSD is
> > decidedly more advanced.
> >
> > > > I could return to a text console in the dark and type "shutdown
> > > > -r
> > now" or even type the command to go back into X, successfully.
> > > In general, this can work.  It did last time I tested, but that
> > > was some time ago so things might have changed.
> >
> > When I tried with new Xorg and KMS in 9-STABLE, my system froze
> > immediately, not just the console.  I finally managed to downgrade
> > to the old Xorg after considerable difficulty.
> >
> > I'd like to try again on a new computer, with FreeBSD-current/HEAD
> > (10.0 is in the not-so-distant future?).
> >
> > With 3 TB hard drive and GPT, I have plenty of space and partitions
> > to experiment, and probably less hazardous than the stablest
> > versions of NetBSD.
> >
> > > > With serial ports becoming obsolete, what can one use for or in
> > > > place
> > of a serial console?
> >
> > > FireWire.  I haven't tested myself, but have a look at
> > >
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html
> > > for instructions on how to use FireWire as a console.
> >
> > This still leaves the question of how to set it up in terms of
> > hardware. I don't think there are any FireWire consoles.
> >
> > Would I plug anything into the motherboard's FireWire port?  I just
> > thought of FireWire-to-HDMI cable but haven't looked to see if
> > these exist.
> >
> > > > Would it work to have two xorg.conf files, one with Intel
> > > > driver and
> > the other with vesa?  Then could you go back to a working console
> > when using the vesa driver?
> > > Once you've loaded the KMS awawre kernel module, there is no way
> > > to get the console back short of a reboot of the system.
> >
> > But would starting X with vesa driver load the KMS awawre kernel
> > module?
> >
> > What about "xorg -configure" which I might want to do the first
> > time?
> >
> > > > I've wondered (call it X acrobatics) how to switch between root
> > > > and
> > nonroot, and between window managers, without going back to text
> > console.
> > > You could try some sort of desktop manager, such as gdm or kdm.
> > > I've not used them on FreeBSD, but on linux they make it possible
> > > to have several users logged into X at once, and switching window
> > > manager, and so on.  As for root, it is generally considered a
> > > bad idea to run X as root.  If it's just a root terminal you
> > > need, you can always open an xterm (or your favorite terminal
> > > emulator) and use su or sudo. Regards!
> > > --
> > > Niclas Zeising
> >
> > On Linux (Slackware) I was only able to have one user at a time
> > using xdm.
> >
> > But I remember one menu item in KDE was konsole as root user
> > (konsole is KDE's X terminal).
> >
> > On NetBSD, xdm completely failed to run.
> >
> > But I got some ideas from Gentoo Linux emailing list, haven't tried
> > yet.
> >
> > One very common mistake people make when attempting to use Intel
> > KMS is to
> either add the KMS driver to loader.conf or to load it manually after
> booting. The result will be an immediate system lockup. Actually, I
> suspect the system is not frozen, but the display is frozen and
> nothing will accept keyboard or mouse input, so it looks frozen.
> 
> Starting X will load the driver at the proper time so that X can
> takeover the display, keyboard, and mouse properly.
> 
> I might also note that Intel KMS requires: WITH_NEW_XORG, WITH_KMS,
> and the build of graphics/libdrm with the KMS config option enabled.
> 
> If I sent this to you in the past, sorry. I have posted this
> information a few times and it may or may not make a difference for
> you.

I have not tried the Intel KMS as I have no applicable hardware, but I
have read plenty of reports from people testing. I had assumed that
when the KMS driver loads, it owns the video card and the kernel never
gets to take it back. Does it also take over keyboard and mouse in some
way? If so, that makes the problem worse and explains why some seem to
have trouble getting a clean reboot/shutdown. I can't fathom why a
video driver would take ownership of input devices.

The VT switching issue doesn't seem like it should be a big one to
solve. The kernel knows how to reinitialize the video card in text mode
as it already relies on that to switch to a text console while UMS Xorg
is running. I first thought the issue with KMS was simply that there
was not a provision for the kernel to tell the KMS driver to give up
the card. However, unloading the module still doesn't give the video
card back so there is something more than meets the eye.