Fwd: [9fans] VBE 1.2/2.0+ functions for Plan9

Fwd: [9fans] VBE 1.2/2.0+ functions for Plan9

[Bob Hartley]

Please correct me if I am wrong on this:
Is it true that the XFree86 device driver modules are platform 
portable, as long as they are for the same instruction set 
architecture?  For some rason I thought the Linux and BSD mobs could 
swap video drivers around amoungst themselves.

If so, would it be possible to create some sort of adapter code that 
would wrap the x11 device drivers for Plan9 use?

Sorry if this is a naive/misbegotten thought,

regards,

Robert

> On Nov 25, 2004, at 1:57 PM, Devon H. O'Dell wrote:
>
>> rog@vitanuova.com wrote:
>>>> I got some tips to look in Inferno code, since Roger Peppe had
>>>> implemented a VESA driver there.  After looking through the Inferno
>>>> source, it appears that any VESA code has been left out of the 
>>>> public
>>>> source.
>>> the code is here:
>>> 	http://www.vitanuova.com/dist/vesa.tgz
>
> <snip>
>
>>>   cheers,
>>>     rog.
>>
>> Thanks for this code, Roger! I'm definitely going to take a look at 
>> it. I think I'm going to start with a VBE3.0 driver, since that can 
>> be implemented fully in protected mode, and then look at implementing 
>> some kind of emulation (similar to what XFree86 might do) for VBE 1.2 
>> and 2.0. This is a real help for that, in any case. You'll definitely 
>> hear from me if I've got questions :).
>>
>> Kind regards,
>>
>> Devon H. O'Dell
>>
>

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[boyd, rounin]

> If so, would it be possible to create some sort of adapter code that 
> would wrap the x11 device drivers for Plan9 use?

two words:  hideous mess

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Russ Cox]

> Please correct me if I am wrong on this:
> Is it true that the XFree86 device driver modules are platform
> portable, as long as they are for the same instruction set
> architecture?  For some rason I thought the Linux and BSD mobs could
> swap video drivers around amoungst themselves.

As long as you want to use them for X.

> If so, would it be possible to create some sort of adapter code that
> would wrap the x11 device drivers for Plan9 use?

Possible?  Yes.  Particularly easy?  Nowhere close.
The X interface is much more complicated than the
Plan 9 interface, and the interface is very different.
In particular Plan 9 splits the job between user space
and the kernel, while X goes through some hoops to
do everything in user space.  I doubt I would want to load
X modules into the kernel, even if someone did do the
huge amount of work to pull it off.

I wonder if instead there is a way to pull the relevant
information out of the code and generate a Plan 9
driver in its place.  That would still be a lot of work, but
the final pieces might be better for our use.

Russ

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Bob Hartley]

Oh well, I was hoping it would be something nice the way the new 
FreeBSD allows loading Windows NIC drivers, except we have access to 
the sources for X11.

I will take a look at this in case some of the drivers are simply table 
driven list of port numbers and data values to write.

Thanks anyways,

Rob

On Nov 25, 2004, at 10:08 PM, Russ Cox wrote:

>> Please correct me if I am wrong on this:
>> Is it true that the XFree86 device driver modules are platform
>> portable, as long as they are for the same instruction set
>> architecture?  For some rason I thought the Linux and BSD mobs could
>> swap video drivers around amoungst themselves.
>
> As long as you want to use them for X.
>
>> If so, would it be possible to create some sort of adapter code that
>> would wrap the x11 device drivers for Plan9 use?
>
> Possible?  Yes.  Particularly easy?  Nowhere close.
> The X interface is much more complicated than the
> Plan 9 interface, and the interface is very different.
> In particular Plan 9 splits the job between user space
> and the kernel, while X goes through some hoops to
> do everything in user space.  I doubt I would want to load
> X modules into the kernel, even if someone did do the
> huge amount of work to pull it off.
>
> I wonder if instead there is a way to pull the relevant
> information out of the code and generate a Plan 9
> driver in its place.  That would still be a lot of work, but
> the final pieces might be better for our use.
>
> Russ
>

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

Bob Hartley wrote:
> Oh well, I was hoping it would be something nice the way the new FreeBSD 
> allows loading Windows NIC drivers, except we have access to the sources 
> for X11.
> 
> I will take a look at this in case some of the drivers are simply table 
> driven list of port numbers and data values to write.
> 
> Thanks anyways,
> 
> Rob

Well, in any case, DragonFly BSD and FreeBSD have quite clean VESA 
implementations supporting versions 1.2 and above (and only what's in 
the spec, all drawing functions will have to be written from scratch). 
I'm in the process of getting a work environment set up, and I think 
that I can get at least the spec accomplished in a relatively short 
amount of time.

WRT other drivers, the only ones that are really of interest would be 
the DRM drivers, these are included and actively developed in FreeBSD 
and DragonFly BSD. X11 drivers are pretty .... unpretty.

I'll keep the list updated on my progress!

--Devon

> On Nov 25, 2004, at 10:08 PM, Russ Cox wrote:
> 
>>> Please correct me if I am wrong on this:
>>> Is it true that the XFree86 device driver modules are platform
>>> portable, as long as they are for the same instruction set
>>> architecture?  For some rason I thought the Linux and BSD mobs could
>>> swap video drivers around amoungst themselves.
>>
>>
>> As long as you want to use them for X.
>>
>>> If so, would it be possible to create some sort of adapter code that
>>> would wrap the x11 device drivers for Plan9 use?
>>
>>
>> Possible?  Yes.  Particularly easy?  Nowhere close.
>> The X interface is much more complicated than the
>> Plan 9 interface, and the interface is very different.
>> In particular Plan 9 splits the job between user space
>> and the kernel, while X goes through some hoops to
>> do everything in user space.  I doubt I would want to load
>> X modules into the kernel, even if someone did do the
>> huge amount of work to pull it off.
>>
>> I wonder if instead there is a way to pull the relevant
>> information out of the code and generate a Plan 9
>> driver in its place.  That would still be a lot of work, but
>> the final pieces might be better for our use.
>>
>> Russ
>>
> 
> 
> 

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[rog]

> I thought earlier grumbles about VESA support were about hardware vs.
> software cursors and some related gymnastics?

yes, i'd forgotten about this.

when i did the VESA support for inferno, it had software cursor support.
it might be quite a pain to put it back into plan 9.

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

Tiit Lankots wrote:
>> Because VBE will work on all the cards that have been manufactured in  
>> the last 8 years and SNAP won't.
> 
> 
> Dream on. You seriously think that every backalley bastard card implements
> VBE? SNAP has the best coverage i've seen so far, and it's very compact at
> it + has been thoroughly tested.

No, I'm aware that not all of them do. But perhaps you should take your 
hostility somewhere else, because I'm certainly not finding it helpful. 
I've gotten a good bit of positive response when I started this thread, 
from both users and developers. If you want to do SNAP for Plan 9, by 
all means do so. I'm not stopping you. I'm also not interested in 
porting it over.

I'm asking for help implementing real mode trap code to do in-kernel 
execution-time 16-bit calls and if you're not interested in that, please 
just don't contribute to the thread. If you'd like to lambast me, please 
do it privately.

Thanks,

Devon

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Tiit Lankots]

> Because VBE will work on all the cards that have been manufactured in  
> the last 8 years and SNAP won't.

Dream on. You seriously think that every backalley bastard card implements
VBE? SNAP has the best coverage i've seen so far, and it's very compact at
it + has been thoroughly tested.

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

Tiit Lankots wrote:
>> Well, I must admit, I'm not the best assembly developer out there. 
>> I've  been taking a look at how DragonFly BSD [1] and NetBSD [2] are 
>> doing it  [executing real mode code under protected mode], and I'm 
>> having a bit of  trouble understanding how it works.
> 
> 
> Why bother. My bet would be on SciTech's SNAP; they recently released it
> under some GPL. I've been playing with it and it seems nice enough
> to warrant some poking around. Alas, I don't have the time right now.

Because VBE will work on all the cards that have been manufactured in 
the last 8 years and SNAP won't.

--Devon

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Tiit Lankots]

> Well, I must admit, I'm not the best assembly developer out there. I've  
> been taking a look at how DragonFly BSD [1] and NetBSD [2] are doing it  
> [executing real mode code under protected mode], and I'm having a bit of  
> trouble understanding how it works.

Why bother. My bet would be on SciTech's SNAP; they recently released it
under some GPL. I've been playing with it and it seems nice enough
to warrant some poking around. Alas, I don't have the time right now.

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

rog@vitanuova.com wrote:
>>I got some tips to look in Inferno code, since Roger Peppe had
>>implemented a VESA driver there.  After looking through the Inferno
>>source, it appears that any VESA code has been left out of the public
>>source.
> 
> [snip]
> life would have been much easier if i had been able to figure
> a way of invoking 16-bit BIOS calls from 32-bit real mode,
> but i failed. anyone know how? other systems seem to manage it.
> 
> my memory is very rusty, but email me if you want help figuring
> out my crappy code!
> 
>   cheers,
>     rog.

Well, I must admit, I'm not the best assembly developer out there. I've 
been taking a look at how DragonFly BSD [1] and NetBSD [2] are doing it 
[executing real mode code under protected mode], and I'm having a bit of 
trouble understanding how it works.

If somebody with more assembler experience might be able to help me go 
through this code to understand what's happening, or would be able to 
work on implementing it with me, this would be highly appreciated. 
Specifically, I can follow the flow of the code (I'm not completely 
hopeless ;)), but I don't understand why certain values and registers 
are used in their context.

When this is done, implementing the VBE 1.2/2.0/3.0 functions will be 
quite a snap. So, anybody who can give me a hand, I invite you to please 
do so! I'm pretty easy to contact for live discussion on most chat 
media; see http://www.the-bofh.org/contact.html for a pretty 
comprehensive list. Of course, email works too :). Don't be shy!

Kind regards,

Devon H. O'Dell

[1] 
http://dragonfly.the-bofh.org/cgi-bin/cvsweb.cgi/src/sys/i386/i386/vm86bios.s?rev=1.12&content-type=text/x-cvsweb-markup

[2]
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/i386/kvm86call.S?rev=1.4&content-type=text/x-cvsweb-markup

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Jack Johnson]

On Thu, 25 Nov 2004 17:13:26 0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> life would have been much easier if i had been able to figure
> a way of invoking 16-bit BIOS calls from 32-bit real mode,
> but i failed. anyone know how? other systems seem to manage it.

You might want to check out Bluebottle:

http://bluebottle.ethz.ch/

The VESA support seems to be rock-solid, though I haven't dug through
the drivers to see how it's implemented.  I recommend downloading the
ISO and booting it live to peek through the sources.

Though the UI will take a little getting used to, the Oberon code
should be easily read by anyone even semi-familiar with Limbo, Java,
Modula or Pascal.  Speed seems to be more dependent on the video
card's implementation than anything (Nvidia seems to have especially
fast VESA support).

I thought earlier grumbles about VESA support were about hardware vs.
software cursors and some related gymnastics?

-Jack

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

rog@vitanuova.com wrote:
>>I got some tips to look in Inferno code, since Roger Peppe had
>>implemented a VESA driver there.  After looking through the Inferno
>>source, it appears that any VESA code has been left out of the public
>>source.
> 
> 
> the code is here:
> 
> 	http://www.vitanuova.com/dist/vesa.tgz
> 
> it was done for an earlier version of inferno, but should
> still be applicable (probably with some changes - i haven't looked
> at it for years).
> 
> at the time, most video cards i found did not implement VBE2.0
> so there's some probe code taken off the net that probes the
> card kind to see how to do bank swapping.
> presumbly VBE2.0-compatible cards are more prevalent now,
> which allow the portable setting of a linear framebuffer -
> it would be nice to remove that dross
> 
> the main complexity is that the vid card setup must be done in
> 16 bit mode, so it has to be done in 16-bit assembler before
> the main bootstrap runs. this is done in boot-pc/l16.s,
> which presents a menu of possible video modes, allows the
> user to select one and presents a test display to allow the user
> to verify that the mode works.
> 
> most of the code is there (in l16.s) - other changed stuff deals
> with bank swapping (mentioned above), passing the
> video params through to the main kernel (this will probably have
> changed), and stealing the SVGA font so that the bootstrap
> knows how to print stuff (since the bootstrap code is entered
> in graphics mode, not CGA mode, so we can't easily print chars).
> 
> life would have been much easier if i had been able to figure
> a way of invoking 16-bit BIOS calls from 32-bit real mode,
> but i failed. anyone know how? other systems seem to manage it.
> 
> my memory is very rusty, but email me if you want help figuring
> out my crappy code!
> 
>   cheers,
>     rog.

Thanks for this code, Roger! I'm definitely going to take a look at it. 
I think I'm going to start with a VBE3.0 driver, since that can be 
implemented fully in protected mode, and then look at implementing some 
kind of emulation (similar to what XFree86 might do) for VBE 1.2 and 
2.0. This is a real help for that, in any case. You'll definitely hear 
from me if I've got questions :).

Kind regards,

Devon H. O'Dell

Re: [9fans] VBE 1.2/2.0+ functions for Plan9

[rog]

> I got some tips to look in Inferno code, since Roger Peppe had
> implemented a VESA driver there.  After looking through the Inferno
> source, it appears that any VESA code has been left out of the public
> source.

the code is here:

	http://www.vitanuova.com/dist/vesa.tgz

it was done for an earlier version of inferno, but should
still be applicable (probably with some changes - i haven't looked
at it for years).

at the time, most video cards i found did not implement VBE2.0
so there's some probe code taken off the net that probes the
card kind to see how to do bank swapping.
presumbly VBE2.0-compatible cards are more prevalent now,
which allow the portable setting of a linear framebuffer -
it would be nice to remove that dross

the main complexity is that the vid card setup must be done in
16 bit mode, so it has to be done in 16-bit assembler before
the main bootstrap runs. this is done in boot-pc/l16.s,
which presents a menu of possible video modes, allows the
user to select one and presents a test display to allow the user
to verify that the mode works.

most of the code is there (in l16.s) - other changed stuff deals
with bank swapping (mentioned above), passing the
video params through to the main kernel (this will probably have
changed), and stealing the SVGA font so that the bootstrap
knows how to print stuff (since the bootstrap code is entered
in graphics mode, not CGA mode, so we can't easily print chars).

life would have been much easier if i had been able to figure
a way of invoking 16-bit BIOS calls from 32-bit real mode,
but i failed. anyone know how? other systems seem to manage it.

my memory is very rusty, but email me if you want help figuring
out my crappy code!

  cheers,
    rog.

[9fans] VBE 1.2/2.0+ functions for Plan9

[Devon H. O'Dell]

Hello list,

I know it's been discussed a lot in the list before, and scoffed at due 
to various reasons (having to hack to activate the VESA support in the 
first place, it not necessarily being SMP-safe and the fact that it's 
not accellerated), but I'd like to implement VESA support for Plan9. I 
got some tips to look in Inferno code, since Roger Peppe had implemented 
a VESA driver there. After looking through the Inferno source, it 
appears that any VESA code has been left out of the public source.

I've tried Plan9 a couple times in the past 6 or 7 years, and have only 
successfully used it a couple of times due to unsupported video. I'm 
interested in writing a VESA driver. I know it's slow, but at least 
it'll allow Plan9 to support 90-something percent of the video cards 
manufactured in the last N years. Whether or not it is accellerated, 
it's better than nothing at all.

I'm writing to the list to ask if anybody has already started on this 
perhaps sometime in the past and has code left over that I could start 
with. If the code is available under a BSD or similar license, that'd be 
great, because I'd like the code to be available under a BSD or similar 
license.

Otherwise, is anybody interested in working with me on this? I'll need 
to do a decent bit of source code reading and such before I can be 
productive, but I'm wanting to start right now. Any / all help and tips 
would be appreciated.

Kind regards,

Devon H. O'Dell