[ANNOUNCE]: VM86 Daemon

[ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

Hi,

A few weeks ago, a discussion on reviving the vesafbd project by Aki
Laukkanen, methods on initializing non-primary cards, and on how to
gather monitor information via DDC/EDID were ongoing at approximately
the same time.  It seems a nice idea to get this information from the
Video BIOS, and so I started on writing vm86d.

The vm86d is a user daemon that accepts requests from the kernel,
processes those requests, and gives the result back to the kernel.  The
communication is done via a miscellaneous character device /dev/vm86. 
The requests can be anything, but currently supports only BIOS services,
predominantly VBE (int 0x10 function 0x4f).  How the daemon processes
those requests is irrelevant, but is currently done via LRMI. 

The vesafb functionality is extended by using various Core and DDC VBE
services.  If the EDID data is available, a table of video modes are
constructed in struct fb_videomode format.  If the monitor is GTF
capable, then modes can actually be computed via the GT formula.  The
result is a vesafb driver that supports video mode changing, cmap
loading, and display panning.  Of course, the latter two functionality
can be done via the protected mode interface, but not all BIOS'es have a
working PMI.

In theory, other fbdev drivers can also use some of the vm86
functionality, notably DDC, EDID parsing, and even video mode changing.

The code is very preliminary, very incomplete, and no attempts were made
to beautify or optimize the code.  I have successfully tested vesafb
against DirectFB, mplayer -vo fbdev, and XFree86 fbdev, using various
modes and pixelformats.  Changing console window size using stty also
works.

There are still a lot of problems to iron out.  EDID parsing is probably
only 70-75% complete.  The EDID data I get from my displays are very
incomplete.  Hopefully, someone can send me their EDID data.  You can
get the read-edid utility, and do a 

'get_edid > edid.dmp', 

and send the dump either directly to me or to this mailing list.  I will
greatly appreciate it.

Other things to do:  Support and initialization of more than 1 card, a
modular vesafb, more robust error checking, extending vm86d to execute
non-BIOS code, to name a few.

It is very unlikely that this will get into the main kernel tree, but if
you are willing to try this out, the package is at:

http://i810fb.sourceforge.net/vm86d-0.1.tar.gz

It will require linux-2.5.66. The main reason for using an unstable
kernel is because it requires some of the features of the new
framebuffer framework to avoid scheduling problems. 

Please browse the README file for installation instructions.

Tony






-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Jon Smirl]

I didn't read through the code yet, is this being
implemented by adding some new IOCTLs to the fb
interface? For example an IOCTL to get the legal modes
or to reset the card.

Why does it need /dev/vm86, couldn't it just use the
fb device and add some new IOCTLS?

I would expect to the end user app to only interact
with the /dev/fb, it would be unaware of the daemon.
This would allow these functions to be transparently
added to the driver if the need hardware info becomes available.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Kendall Bennett]

Jon Smirl <jonsmirl@yahoo.com> wrote:

> I didn't read through the code yet, is this being implemented by
> adding some new IOCTLs to the fb interface? For example an IOCTL to
> get the legal modes or to reset the card. 

We definitely want some new IOCTL's to allow the apps to find out what 
modes are available, if this has not been added.

> Why does it need /dev/vm86, couldn't it just use the fb device and
> add some new IOCTLS? 

Yes, it could. However when Tony discussed this with me a week or so ago, 
he figured that since vesafb is just using basic vm86() functions from 
the kernel, it is a lot more modular and useful to make the daemon just a 
vm86() daemon for kernel code. Then it can be used for other stuff that 
has a need to make real mode BIOS calls that just the vesafb driver.

> I would expect to the end user app to only interact with the
> /dev/fb, it would be unaware of the daemon. This would allow these
> functions to be transparently added to the driver if the need
> hardware info becomes available. 

As I understand it the /dev/vm86 interface is there solely to implement 
the vm86() interfacing to the kernel, which is used by the modified 
vesafb driver. Userland apps only ever call the /dev/fb functions via the 
standard IOCTL's and never need to care that /dev/vm86 exists or not. It 
is clean separation, and as you said if the fb driver can drive the 
hardware directly without the need to use the vm86d daemon, it is 
transparently ignored by any and all fb console apps ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 08:07, Jon Smirl wrote:
> I didn't read through the code yet, is this being
> implemented by adding some new IOCTLs to the fb
> interface? For example an IOCTL to get the legal modes
> or to reset the card.
> 

It uses a dedicated device, /dev/vm86, which is unrelated to fb.

> Why does it need /dev/vm86, couldn't it just use the
> fb device and add some new IOCTLS?

A new device seems more powerful and more generic.  Generic in a sense
that other subsystems besides fbdev can use it to access the BIOS or
whatever.  More powerful because a dedicated device is also provided
with the functionality of the file system.  The daemon uses file
read/write to access data, select/poll to wait for device ready, and 1
ioctl call to let /dev/vm86 know that the daemon is loaded or to be
unloaded. If async IO works for regular files, it will also have that
functionality.
 
> 
> I would expect to the end user app to only interact
> with the /dev/fb, it would be unaware of the daemon.
> This would allow these functions to be transparently
> added to the driver if the need hardware info becomes available.
> 

Yes.  Behavior of /dev/fbX is still the same, except that when vm86d is
loaded, it provides additional functionality to vesafb. The user will
not notice that vm86d is there, except that he/she and applications can
now change the video mode. 

Tony
 
> =====
> Jon Smirl
> jonsmirl@yahoo.com
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 08:27, Kendall Bennett wrote:
> Jon Smirl <jonsmirl@yahoo.com> wrote:
> 
> > I didn't read through the code yet, is this being implemented by
> > adding some new IOCTLs to the fb interface? For example an IOCTL to
> > get the legal modes or to reset the card. 
> 
> We definitely want some new IOCTL's to allow the apps to find out what 
> modes are available, if this has not been added.

Actually, the fbdev has its own ioctl, FBIOSETVAR (or something like
that).  You place the desired mode in struct fb_var_screeninfo (var),
then set var->activate = FB_ACTIVATE_TEST.  If there's no error, the var
should now contain the best mode (not necessarily the same) which was
requested. 

All this is automatically incorporated to vesafb when vm86d is loaded. 
The new vesafb driver has additional methods for:

fb_check_var()
fb_set_par()
fb_pan_display()
fb_setcolreg()
fb_blank() -- currently a dummy method

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Jon Smirl]

--- Antonino Daplas <adaplas@pol.net> wrote:
> A new device seems more powerful and more generic. 
> Generic in a sense
> that other subsystems besides fbdev can use it to
> access the BIOS or

The new device is going to need to sort out multiple
adapters. Using /dev/fbX avoids that problem. You'll
also be able to get the /dev/fb code into the kernel.
Getting a driver in that creates /dev/vm86 is going to
be harder. 

I'm not clear on what /dev/vm86 does. Why couldn't the
radeon driver exec vm86d with a parameter of /dev/fb0.
vm86d would then open/IOCTL the radeon driver to
identify the PCI device and what actions are needed.
After it resets and gets the EDID data it would IOCTL
them back into /dev/fb0 and exit. You need to know
which PCI device so that you can set up the right
VBIOS ROM. Each adapter would get it's own vm86d, but
they wouldn't hang around long.

I haven't played with this yet but the vm86d should
use the new klibc. That would allow it to run early in
the boot process. The driver could then exec it if
needed. It would also make vm86d tiny.

The Radeon and Rage128 cards need a reset if they are
reporting zero VRAM.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Benjamin Herrenschmidt]

This is interesting, but brings back a point I had in mind
for some time (regardless of having that daemon or not), which
is to provide a consistent API for fbdev's to provide EDID
informations to a "monitor" layer (or to userland) and for
fbdev's to setup appropriately based on EDID informations.

There are several issues here. One is the actual retreival of
the EDID data. There are several ways to do it, and all of them
must be implemented in an ideal world:

 - BIOS stuff (via something like your daemon)
 - Direct i2c (for all platforms that don't have a BIOS or cannot
   run it)
 - Other arch specific way (this includes what we do on some PPCs
   which is to retreive the EDID block from the device tree provided
   by the firmware).

Once the fbdev can provide, upon request, the EDID and probing info
(some cards can tell you if something is connected even without
providing an EDID, like on the S-Video output, or on the VGA output
with a non-DDC capable monitor), we need some consistent API to
retreive that from, userland at least

Then, we need fbdev to "validate" modes based on those EDID infos
(via fbmon ?).




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 12:01, Jon Smirl wrote:
> --- Antonino Daplas <adaplas@pol.net> wrote:
> > A new device seems more powerful and more generic. 
> > Generic in a sense
> > that other subsystems besides fbdev can use it to
> > access the BIOS or
> 
> The new device is going to need to sort out multiple
> adapters. Using /dev/fbX avoids that problem. You'll

No, it won't.  If multiple graphics adapters are to be supported, what's
needed is a hardware unique identifier that is known to both caller and
callee.  /dev/fbX will not tell you anything about the device.  This
unique ID can be the bus, device and function number.  So whether the
request is done through /dev/fbX or /dev/vm86, the ID must still be
specified.

> also be able to get the /dev/fb code into the kernel.
> Getting a driver in that creates /dev/vm86 is going to
> be harder. 

I would rather have the code rejected than back-dooring it behind fbdev.
If it's going to be accepted, it has to be on its own merit.

> 
> I'm not clear on what /dev/vm86 does. Why couldn't the

/dev/vm86 just controls how data gets to and from the daemon.  What kind
of data passes through it does not matter.  Only the daemon and the
caller should know what protocol is used.

> radeon driver exec vm86d with a parameter of /dev/fb0.
> vm86d would then open/IOCTL the radeon driver to
> identify the PCI device and what actions are needed.
> After it resets and gets the EDID data it would IOCTL
> them back into /dev/fb0 and exit. You need to know
> which PCI device so that you can set up the right
> VBIOS ROM. Each adapter would get it's own vm86d, but
> they wouldn't hang around long.
> 

Yes, in a similar manner, fbdev can pass a request through /dev/vm86
that says "run expansion ROM code of device with this unique ID".  The
daemon will then do just that.  It does not matter if the device is a
VGA controller, or some other PCI device.  It also will not matter if
the expansion ROM is in x86 form, OpenFirmware, etc, it's up to the
daemon.

The hardest part that the daemon will do is maintaining separate virtual
mode environments if the device happens to be a VGA controller.  This is
only needed if the VBIOS are to be consistently required. Other types of
PCI devices should not suffer the same limitation.
 

Tony




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 16:29, Benjamin Herrenschmidt wrote:
> 
> Once the fbdev can provide, upon request, the EDID and probing info
> (some cards can tell you if something is connected even without
> providing an EDID, like on the S-Video output, or on the VGA output
> with a non-DDC capable monitor), we need some consistent API to
> retreive that from, userland at least
> 
> Then, we need fbdev to "validate" modes based on those EDID infos
> (via fbmon ?).
> 

How I'm currently doing it with the extended vesafb driver is this:

1. construct a database of video modes in struct fb_videomode format
based on all the modes given by the EDID.  This database can be passed
to fb_find_mode() in modedb.c to select the best video mode.  If the
monitor's operating limits are unknown, then the driver is restricted to
using only modes listed by the database.

2. If the monitor's operating limits are known (again via EDID), modes
can be easily validated.  There's already working code for this in
fbmon.c -- fb_validate_mode().  

3. If the monitor is GTF-capable, then referring to the database can
actually be skipped, and modelines will just be computed using the VESA
GT formula.  Again, the code is already existent in fbmon.c --
fb_get_mode().  

I've also extended EDID parsing in fbmon.c.  Here's a sample output:

========================================
Display Information (EDID)
========================================
   EDID Version 1.3
   Manufacturer: VSC Model: 2007 Serial#: 16843009
   Year: 2001 Week 47
   Display Characteristics:
      Analog Display Input: Input Voltage - 0.700V/0.300V
      Sync: Separate Composite Sync on Green
      Max H-size in cm: 38
      Max V-size in cm: 30
      Gamma: 2.40
      DPMS: Active yes, Suspend no, Standby no
      RGB Color Display
      First DETAILED Timing is preferred
   Standard Timings
      1280x10240@60Hz
      1280x1024@75Hz
      1152x864@75Hz
      1024x768@75Hz
      832x624@75Hz
      800x600@75Hz
      640x480@75Hz
      640x480@60Hz
   Supported VESA Modes
      720x400@70Hz
      640x480@60Hz
      640x480@67Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      832x624@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      1152x870@75Hz
      Manufacturer's mask: 0
   Detailed Monitor Information
      108 MHz 1280 1328 1440 1688 1024 1025 1028 1066 +HSync +VSync

      Serial No     : A0Y014710490
      HorizSync     : 30-82 KHz
      VertRefresh   : 50-75 Hz
      Max Pixelclock: 140 MHz
      Monitor Name  : VG191
========================================

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Benjamin Herrenschmidt]

On Tue, 2003-04-01 at 11:41, Antonino Daplas wrote:

> How I'm currently doing it with the extended vesafb driver is this:
>
> .../...

Ok, good. I'll investigate adapting that to radeonfb & aty128fb
at least.

Also, It would be very useful if we defined a standard ioctl to
retreive the EDID block from userland when available.

This would help some fbdev based apps (especially the maconlinux
emulator) and would be useful for some distro X autoconfig tools,
especially on platforms where X cannot get that EDID via it's
current mecanisms.

Actually, I would like 2 things:

 - Be able to know that the display has been detected as beeing a
TFT panel, and in this case, a "simple" way to retreive the
fb_var_screeninfo of the "native" panel mode. 

 - Returning the full EDID block when it exist

What do you think about adding some ioctl's for that ?

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 19:34, Benjamin Herrenschmidt wrote:
> On Tue, 2003-04-01 at 11:41, Antonino Daplas wrote:
> 
> > How I'm currently doing it with the extended vesafb driver is this:
> >
> > .../...
> 
> Ok, good. I'll investigate adapting that to radeonfb & aty128fb
> at least.

I'm planning to submit a patch to James to add more functionality to
fbmon.c,  fbmon.c should have these at least:

1. struct fb_videomode* fb_create_modedb(unsigned char *edid)

- this will create a mode database that can be used with fb_find_mode() 

2. fb_destroy_modedb(struct fb_videomode *modedb)

- destroy mode database

3. fb_get_monitor_limits(struct fb_monspecs *specs, unsigned char *edid)

- place monitor operating limits to specs

4. fb_validate_mode(struct fb_var_screeninfo *var, struct fb_info *info)

- validate mode timings in var

5. fb_get_mode(int flags, int val, struct fb_var_screeninfo *var, struct
fb_info *info)

- compute mode timings using GTF (refresh driven, hsync driven, pixclock
driven, or maximized refresh) and place result in var

#4 and #5 are already in fbmon.c


> Also, It would be very useful if we defined a standard ioctl to
> retreive the EDID block from userland when available.
> 

I have no problem with this, and this was discussed some time ago, but
nothing was really decided.  It's actually a very nice fallback solution
if there's really no method to get the EDID.

> This would help some fbdev based apps (especially the maconlinux
> emulator) and would be useful for some distro X autoconfig tools,
> especially on platforms where X cannot get that EDID via it's
> current mecanisms.
> 
> Actually, I would like 2 things:
> 
>  - Be able to know that the display has been detected as beeing a
> TFT panel, and in this case, a "simple" way to retreive the
> fb_var_screeninfo of the "native" panel mode. 
> 
>  - Returning the full EDID block when it exist
> 
> What do you think about adding some ioctl's for that ?
> 

It's okay by me.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [directfb-dev] Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 20:08, Denis Oliver Kropp wrote:
>
> I'm wondering if there are plans to have /dev/fbX provide
> bus/device/function number for easier mapping. It's PCI related,
> but it would help fbDRI etc.
>

Not too sure about this.
 
> > > also be able to get the /dev/fb code into the kernel.
> > > Getting a driver in that creates /dev/vm86 is going to
> > > be harder. 
> > 
> > I would rather have the code rejected than back-dooring it behind fbdev.
> > If it's going to be accepted, it has to be on its own merit.
> 
> If vm86 doesn't (need to) know anything about the framebuffer drivers
> I would prefer an extra device, too.

Yes, /dev/vm86 is completely separate from /dev/fbX.

> 
> Why is it called /dev/vm86 if it's not restricted to x86?
> Sounds more like a /dev/firmwared or /dev/biosd.
> 

It actually started as /dev/vesafb.  It seems that it can still become
more generic.  There are at least 2 ideas on this though:

1.  Make primary protocol x86 encoded, and just let the daemon convert
it to something the backend will understand.  For example, VBE int 0x10
ax = 0x4f01 (Set Video mode), will be encoded by the daemon into another
protocol depending on the backend. This will be easy for /dev/vm86, hard
for the daemon.

2  Make /dev/vm86 also pass non-x86 requests.  This will be hard for
/dev/vm86, but easy for the daemon.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Benjamin Herrenschmidt]

On Tue, 2003-04-01 at 15:38, Antonino Daplas wrote:
> On Tue, 2003-04-01 at 19:34, Benjamin Herrenschmidt wrote:
> > On Tue, 2003-04-01 at 11:41, Antonino Daplas wrote:
> > 
> > > How I'm currently doing it with the extended vesafb driver is this:
> > >
> > > .../...
> > 
> > Ok, good. I'll investigate adapting that to radeonfb & aty128fb
> > at least.
> 
> I'm planning to submit a patch to James to add more functionality to
> fbmon.c,  fbmon.c should have these at least:
> 
> 1. struct fb_videomode* fb_create_modedb(unsigned char *edid)
> 
> - this will create a mode database that can be used with fb_find_mode() 

Interesting. I would like a way for userland to retreive those
entries though, so we don't have to duplicate fbmon functionality
in userland (for example, a mode selection tool). Like for the EDID

> .../...

> > Also, It would be very useful if we defined a standard ioctl to
> > retreive the EDID block from userland when available.
> > 
> 
> I have no problem with this, and this was discussed some time ago, but
> nothing was really decided.  It's actually a very nice fallback solution
> if there's really no method to get the EDID.

Yah. I mistyped, I meant send the EDID to userland, but you are right
about that fact that it would be nice to also have a way for userland
to send it to the driver.

> > This would help some fbdev based apps (especially the maconlinux
> > emulator) and would be useful for some distro X autoconfig tools,
> > especially on platforms where X cannot get that EDID via it's
> > current mecanisms.
> > 
> > Actually, I would like 2 things:
> > 
> >  - Be able to know that the display has been detected as beeing a
> > TFT panel, and in this case, a "simple" way to retreive the
> > fb_var_screeninfo of the "native" panel mode. 
> > 
> >  - Returning the full EDID block when it exist
> > 
> > What do you think about adding some ioctl's for that ?
> > 
> 
> It's okay by me.

Ok, I'll define something & implement it in radeonfb as soon as
I find some time (probably after your fbmon changes get in) for
both the EDID/userland and userland access to the dynamically
created modedb database

BTW. Do you know if it's possible to get some infos/specs on
the EDID format, GF formula, etc... or it's all paying stuffs ?

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Jon Smirl]

--- Antonino Daplas <adaplas@pol.net> wrote:
> 4. fb_validate_mode(struct fb_var_screeninfo *var,
> struct fb_info *info)
> 
> - validate mode timings in var
> 
> 5. fb_get_mode(int flags, int val, struct
> fb_var_screeninfo *var, struct
> fb_info *info)
> 
> - compute mode timings using GTF (refresh driven,
> hsync driven, pixclock
> driven, or maximized refresh) and place result in
> var
> 
> #4 and #5 are already in fbmon.c
>

Wouldn't it be better to make fb_get_mode only return
the list of valid modes based on the hardware and
monitor (if available) combination rather than letting
the app sort it out?

We could then make a new IOCTL fb_get_hwmode for
returning the card's capabilities if more detail is
desired.


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 21:53, Benjamin Herrenschmidt wrote:
> > > 
> > > What do you think about adding some ioctl's for that ?
> > > 
> > 
> > It's okay by me.
> 
> Ok, I'll define something & implement it in radeonfb as soon as
> I find some time (probably after your fbmon changes get in) for
> both the EDID/userland and userland access to the dynamically
> created modedb database
> 
> BTW. Do you know if it's possible to get some infos/specs on
> the EDID format, GF formula, etc... or it's all paying stuffs ?
> 

I think you have to pay VESA for these. 

I used a combination of XFree86, read-edid, and fbmon.c for the EDID
parser. I think Kendall Bennett is planning to release their own code.

As for the GTF, I used the MS Excel spreadsheet available in VESA's ftp
site.  

As for VBE, the VBE 3.0 Core specs is free.  I also referred to Ralph
Brown's comprehensive interrupt list for x86 real mode.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Antonino Daplas]

On Tue, 2003-04-01 at 23:22, Jon Smirl wrote:
> > 
> > 5. fb_get_mode(int flags, int val, struct
> > fb_var_screeninfo *var, struct
> > fb_info *info)
> > 
> > - compute mode timings using GTF (refresh driven,
> > hsync driven, pixclock
> > driven, or maximized refresh) and place result in
> > var
> > 
> > #4 and #5 are already in fbmon.c
> >
> 
> Wouldn't it be better to make fb_get_mode only return
> the list of valid modes based on the hardware and
> monitor (if available) combination rather than letting
> the app sort it out?

Actually, using a combination of functions that will be available in
fbmon.c, the fbdev driver will become independent from userland, such as
/etc/fb.modes. User-entered timings are still preferred thoug, and only
when the timings are invalid that the driver will select the nearest
mode from the database, or calculate one for it.  A theoretical sequence
will be like this:

1. driver rounds off values in var
2. timings in var is validated using fb_validate_mode()
3. if timings are valid, driver accepts the new timings
4. if timings are invalid, it checks if monitor is GTF capable.
5. if monitor is GTF capable, it calls fb_get_mode(). 
6. if monitor is not GTF capable, it calls fb_find_mode(), passing the
database created from fb_create_modedb().

Fbdev needs this independence from userland in order for stty to work,
primarily, and to make it easier for the user, secondarily.

You're correct though that it's a good idea to pass a list of modelines
to userland.  However, the filtering is best done by the driver because
it has the best knowledge on the limits/capabilities of the chipset.

BTW:  fb_get_mode() will only compute a single modeline (using GTF). 
It's fb_create_modedb() that will make a list of video modes.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [ANNOUNCE]: VM86 Daemon

[Benjamin Herrenschmidt]

> Actually, using a combination of functions that will be available in
> fbmon.c, the fbdev driver will become independent from userland, such as
> /etc/fb.modes. User-entered timings are still preferred thoug, and only
> when the timings are invalid that the driver will select the nearest
> mode from the database, or calculate one for it.  A theoretical sequence
> will be like this:
> 
> 1. driver rounds off values in var
> 2. timings in var is validated using fb_validate_mode()
> 3. if timings are valid, driver accepts the new timings
> 4. if timings are invalid, it checks if monitor is GTF capable.
> 5. if monitor is GTF capable, it calls fb_get_mode(). 
> 6. if monitor is not GTF capable, it calls fb_find_mode(), passing the
> database created from fb_create_modedb().
> 
> Fbdev needs this independence from userland in order for stty to work,
> primarily, and to make it easier for the user, secondarily.
> 
> You're correct though that it's a good idea to pass a list of modelines
> to userland.  However, the filtering is best done by the driver because
> it has the best knowledge on the limits/capabilities of the chipset.

How do you fit in this picture using scaled modes ? Typically, LCDs
only really using their "native" mode, but any lower-sized mode can
be obtained using the scaler (I've just fixed bugs in radeonfb for
that btw). In this case, what list do we "propose" to userland ?
A list of 'standard' well known modes in addition to the native one ?

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Small API change

[Benjamin Herrenschmidt]

I want to add a flag passed by userland in fb_var_screeninfo
that say, for an LCD using a scaled mode, to either use a full
scaling or to keep aspect ratio (when possible).

This is quite useful for things like titanium powerbooks with their
wide LCDs. Currently, if I set a 1024x768 mode on my 'native' 1152x768,
I get a horizontal scaling and no vertical scaling, thus a bad
aspect ratio. It can be ok for some things, not for others, I'd like
to let userland the choice. MacOS does provide both set of modes
as well. In the "keep aspect ratio" mode, the driver would scale
both H and V the same (based on the smaller of H and V ratios)
and add margins to center the display. On some radeons, I think I
even have optional HW automatic centering.

We can either define a "flags" field using on of the reserved ones
and stuff that (along with 31 remaining bits for whatever other
flags we may have, I'm thinking about 6 vs. 8 bits DACs or such
other options that are common to enough HW to be worth defining
there).

We can define a "hw_specific_flags" field. Same as above, but we
define the meaning of this field as depending on the driver. That
is, we add a way for userland to pass mode attributes (we are really
talking about mode attributes here, that should be passed along with
setting the mode) that are specific to a given driver, though the
problem of identifying the driver type may not be that simple (using
the accel type constant ?)

Or we can eventually just define a new bit in the "sync" field, that
seem to be the most economic way, since we have 32 bits available
and only 6 used so far




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: Small API change

[Geert Uytterhoeven]

On 1 Apr 2003, Benjamin Herrenschmidt wrote:
> I want to add a flag passed by userland in fb_var_screeninfo
> that say, for an LCD using a scaled mode, to either use a full
> scaling or to keep aspect ratio (when possible).
> 
> This is quite useful for things like titanium powerbooks with their
> wide LCDs. Currently, if I set a 1024x768 mode on my 'native' 1152x768,
> I get a horizontal scaling and no vertical scaling, thus a bad
> aspect ratio. It can be ok for some things, not for others, I'd like
> to let userland the choice. MacOS does provide both set of modes
> as well. In the "keep aspect ratio" mode, the driver would scale
> both H and V the same (based on the smaller of H and V ratios)
> and add margins to center the display. On some radeons, I think I
> even have optional HW automatic centering.
> 
> We can either define a "flags" field using on of the reserved ones
> and stuff that (along with 31 remaining bits for whatever other
> flags we may have, I'm thinking about 6 vs. 8 bits DACs or such
> other options that are common to enough HW to be worth defining
> there).
> 
> We can define a "hw_specific_flags" field. Same as above, but we
> define the meaning of this field as depending on the driver. That
> is, we add a way for userland to pass mode attributes (we are really
> talking about mode attributes here, that should be passed along with
> setting the mode) that are specific to a given driver, though the
> problem of identifying the driver type may not be that simple (using
> the accel type constant ?)
> 
> Or we can eventually just define a new bit in the "sync" field, that
> seem to be the most economic way, since we have 32 bits available
> and only 6 used so far

I think the vmode field is better suited for this than the sync field.

Do you want a `positive' (keep aspect ratio) or `negative' (allow stretching)
flag? And what about stretching that doesn't involve changing the aspect ratio?
E.g. do you want 640x480 to be stretched to 1024x768, or not stretched and
centered?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: Small API change

[Benjamin Herrenschmidt]

On Tue, 2003-04-01 at 22:10, Geert Uytterhoeven wrote:

> I think the vmode field is better suited for this than the sync field.
> 
> Do you want a `positive' (keep aspect ratio) or `negative' (allow stretching)
> flag? And what about stretching that doesn't involve changing the aspect ratio?
> E.g. do you want 640x480 to be stretched to 1024x768, or not stretched and
> centered?

Ok, vmode is fine too.

What I had in mind was to keep aspect ratio by default and let full
stretching when that bit is set. I want 640x480 to be stretched to
1024x768 and then centered on my 1152x768 screen.

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: Small API change

[James Simmons]

> > I think the vmode field is better suited for this than the sync field.
> > 
> > Do you want a `positive' (keep aspect ratio) or `negative' (allow stretching)
> > flag? And what about stretching that doesn't involve changing the aspect ratio?
> > E.g. do you want 640x480 to be stretched to 1024x768, or not stretched and
> > centered?
> 
> Ok, vmode is fine too.
> 
> What I had in mind was to keep aspect ratio by default and let full
> stretching when that bit is set. I want 640x480 to be stretched to
> 1024x768 and then centered on my 1152x768 screen.

Cool. I agree vmode is the best stop. Just send me a patch and I will 
apply it.




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: Small API change

[Benjamin Herrenschmidt]

On Thu, 2003-04-03 at 00:01, James Simmons wrote:

> > 
> > What I had in mind was to keep aspect ratio by default and let full
> > stretching when that bit is set. I want 640x480 to be stretched to
> > 1024x768 and then centered on my 1152x768 screen.
> 
> Cool. I agree vmode is the best stop. Just send me a patch and I will 
> apply it.

Ok, as soon as I have it working properly, I'll send that along with
a bunch of radeonfb updates. (I've been fixing a bunch of things on
the 2.4 codebase and didn't fully update the 2.5 driver yet)

Ben.



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/