Re: Windows Assembly

Richard Cooper wrote:
>> I really don't get why people started hacking away at X the way they
>> did, rather than constructing a proper kernel-mode video driver
>> architecture first. The mentality of having the graphics support at
>> application rather than kernel level is SO out-of-date DOS mentality.
>
> I'm all for having everything in user space that can be there, but
> they way they're doing it is just wrong.

I'm for having "what makes sense" in user space :). Some people want to put
everything in the kernel, and some want to put everything in user-space - I
think both factions are wrong. If you put too much in user space, you risk
ending up calling kernel functions all the time, causing an insane amount of
context switches - bad. If you put too much in the kernel (the ring0 part,
mind you), you risk being very vulnerable to bugs.

IMHO video drivers belong in the kernel, so that the drivers can take
advantage of whatever acceleration the hardware offers, and offer a nice
standard API and reduce programmers' headaches and wheel-reinventing.

> When the system starts, there should be one program (which I'll call
> the video driver) that accesses the video card, and uses sockets or
> something to accept connections from other programs on the system.

Sockets is probably too high overhead for something as speed-sensitive as
graphics; syscalls will probably be best, also considering that the video
driver ought to be kernel component.

> Each program that connects to it runs full screen, and you can switch
> between those programs with the Alt-Fn sequence.

Sounds sensible enough. The kernel would be responsible for the necessary
mode changes, not each and every individual app.

> Then to get your virtual consoles, you start up about six VT-100
> emulators which connect to this video driver, and the video driver
> lets you switch between them with Alt-Fn, and there's your virtual
> consoles.

Well, the VT-100 emulators would use the console subsystem which in turn
would communicate with the video driver - but yes.

> X would also connect to this video driver, and thus X gets to stop
> being Linux's video driver and start being simply a program that
> implements the X protocol.

Ex-act-ly. The current design is braindamage, pure and simple. Having X rely
on kernel video drivers also means that the developers would be forced to
think up a decent API, since hardware acceleration kinda is necessary to
have decent speed in a window managing system.

> Additionally, if you start up a program under X, it can detect this,
> and instead of connecting to the video driver, it can connect to
> another program that uses the same protocol, but converts everything
> to the X protocol and sends it to the X server. So anything that ran
> in console would also run in X, including those VT-100 emulators.

Obviously there needs to be some form of integration between X and the video
drivers - implemented via hooks and whatnot to make it generic enough for
not just X to use it. Like, an application can specify "I want to set this
video mode", together with a flag that tells the driver whether fullscreen
is required. If an app runs under X and doesn't require fullscreen, it will
automagically run in windowed mode.

Applications that don't need graphics mode would just interface with the
console subsystem (or not even do that directly, but simply use read/write,
which in turn interfaces with the console subsys), and because the console
subsys interfaces with the kernel drivers, nothing fancy has to be done for
console apps.

> However, given that everything else in Linux is in the kernel, it
> would make a lot of sense for the video driver to be in there as
> well. However, Linux does no management to share the video device
> currently, and programs just have to cooperate when using it, so I'd
> be afraid that if they went that route they'd do it the same way, and
> thus video support would only be a little bit better.

Somebody needs to give the linux kernel team a good beating and drag them
out of the 70es. Or perhaps we should just sit back and wait until Mac OS X
is fully ported and publicly available for x86 hardware. IMHO, it's the only
real alternative to windows.

>> Unfortunately rumors go that a whole bunch of recent video
>> cards don't have VBE3 functionality,
>
> VBE3? Why not just use VESA 1.2. I used 1.2 under DOS and it was
> incredibly easy to use, even with the bank switching. Bank switching
> is not the slightest bit difficult as long as you're not trying
> something stupid like writing a line drawing algorithm that draws
> directly to the screen instead of into a buffer. I don't know what
> the difference is between 1.2 and earlier versions, but there may not
> even be any reason to require 1.2.
>
> Even if it's a bit slower with 1.2 and the bank switching, it's still
> much better than nothing at all.

True. But unless I need blending effects (or other things that require
read-back from video memory), I think I'd prefer to draw directly to the
video card backbuffer instead of using an intermediary system memory buffer.
System buffers become a bit slow in high-res modes unless you have some more
intelligent blitting code than simply copying everything over. Ok,
1024x768x32bpp @ 30fps is only something like 90mb/s, but still...

> I thought about calling the VESA bios myself, but I couldn't find any
> documentation on the 8086 mode system call, so I didn't know where to
> begin. Stealing the code from X wasn't an option, because Softer is
> public domain, and that clashes with the not as free GPL.

GPL: as free as a police state :)

> I wouldn't trust code out of X to be bug-free anyway, and I doubt they'd
> have enough comments that I would know what they were doing and could
> verify they weren't doing anything wrong.

Probably true. Wouldn't hurt browsing through the XF86 vesa driver and see
if there's some interesting calls being made, to get an idea where to start
looking. There must really be some kernel mode support, since dong v86 by
hand is quite some work.


.

Relevant Pages

  • tsc problems in 2.6.0-test11
    ... I'm not using speedstep or any voltage altering cpu code in the kernel. ... Using tsc for high-res timesource ... Doing some strenuous video ... # ACPI Support ...
    (Linux-Kernel)
  • Re: [opensuse] NVIDIA drivers
    ... that video cards and their driver are unavoidable hardware/firmware. ... I could understand a moral standpoint from the kernel developers if they ... It would be interesting to know which video driver each of the kernel ... We make business with distributing the Linux kernel, ...
    (SuSE)
  • Update on Timer Frequencies
    ... world experience comparing the 2.6.14 kernel compiled with the timer ... I'm running a video server that is taking in and sending out ... it's not a perfect test to evaluate timer frequencies (because it doesn't ... Each test is really a sequence of scripts that a) run dd on a trio of one ...
    (Linux-Kernel)
  • Re: Windows Assembly
    ... > just calling the kernel, and making one context switch, you call the ... > which is two context switches. ... video drivers in userspace too? ... > linear buffer that's one byte per pixel and make everything draw into ...
    (alt.lang.asm)
  • Re: best framebuffer for YD 3.0.1 on 604e?
    ... > I boot her up? ... the kernel arguments only affect - ... video and XFree86 video, and ... failsafe XF86Config and then tweak it to explicitly define the BusID ...
    (comp.os.linux.powerpc)