vtc(4) and graphics drivers.
Posts to mailing lists relating to the graphical console have increased with the growing popularity of the amd64 port. I’m not at all surprised about this. In fact, I’ve seen it coming. That’s why I started vtc(4) development many moons ago. With KGI declared dead, vtc(4) may have grown another leg to stand on: a breeding ground for future KGI development. A new leg does not mean that vtc(4) has a more viable future. The fact that vendors of graphics cards keep their hardware under NDA is a real hurdle for vtc(4) and having proper drivers for graphics hardware is central to the design and implementation. If not for getting the higher resolution, real drivers are needed to get any kind of acceptable performance out of the hardware. Good performance is another hurdle that needs to be overcome. I just ran a kernel with vtc(4) under Parallels (a virtualization package that runs on Mac OS X for Intel processors) and scrolling was painful to watch. Interestingly, Parallels simulates Intel graphics hardware and Intel has documented what which is important to vtc(4). It would be interesting to write a driver for GMCH hardware with accelerated bitblt operations and see if there’s a performance increase. That’s an interesting experiment…
July 14th, 2006 at 5:47 pm
Modesetting code (and trivial 2d acceleration) exists in X.Org for every card I know of except for the ATI Radeon x1000 series. We’ve got enough information for the basics on the x1000 series from airlied’s work, but the code hasn’t been written. So NDAed specs (not that NDAed specs for the big 3 even really get given out to open source folks these days) aren’t an issue because you’ve already got implementations.
The real problem here is that if you want to put this stuff into the kernel, it means writing reams and reams of miserable modesetting code for every chipset out there. I think the intel modesetting code is going to be on the order of about 10,000 lines when I’m done with it. Now, do that about 20 times for all the different chipsets out there. And have FreeBSD, or even *BSD, alone maintain it? Riiiiight. Learn from the linux fbdev experience. X doesn’t even have this code all working right, and it’s probably got orders of magnitude more users.
This is why I’ve been advocating that, if anyone’s going to try to get better modes in console, modesetting should get split out from X into userland libraries. Then, we can have a daemon called out to by the kernel for the kernel’s modesetting responsibilities, and X could use the same stuff for its support. I think at this point we’ve got a pretty reasonable idea of what the API the library would need to support would look like, too.
The 2d acceleration necessary for console is really trivial.
July 14th, 2006 at 11:13 pm
The argument that mode-setting should be done in userland because the code is already out there to do it, is strong. Unfortunately, it’s also an argument that proposes a solution for only parts of the problem-space. Mode-setting needs to be done before user-space is functional, even if it doesn’t have to be done on PCs. On top of that, the kernel needs to know about the mode and its operation because it’s fundamental in the event of crashes as well as working in the kernel debugger.
So far, the old argument that it should be done in user-space, continues to ignore the complete scope of the problem or handwaves those aspects of the problem it doesn’t address as non-important. That’s a shame, because when all involved parties are ready to solve the same problem space, real cooperation begins and true solutions will see the light of day.
July 26th, 2006 at 2:02 pm
Eddie800 pokervxb