[PATCH v2 0/5] uvesafb: a general description

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

This is the second version of this patch, and it incorporates all fixes
and cleanups suggested on the lkml.  My thanks to everyone who took
their time to review the first version.

uvesafb uses a userspace helper application (v86d, [2]) to run the x86
Video BIOS code.  This makes it possible to include in uvesafb all the
standard features (refresh rate control, video mode changes etc) that
are missing from vesafb without resorting to ugly hacks such as the ones
used in [1].  The current implementation of v86d can use either LRMI or
x86emu to run the BIOS code and supports both x86 and x86_64.

[1] http://dev.gentoo.org/~spock/projects/vesafb-tng/
[2] http://dev.gentoo.org/~spock/projects/uvesafb/

Best regards.
-- 
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Michal Januszewski wrote:

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

  

Hi Michal,

I've just tested uvesafb on my workstation ( which has a really old 
GeForce2 MX 400 Nvidia card ) and it didn't worked here.

If I remember right vesafb-ntg worked here and vesafb works for sure :)

Here the error from dmesg :

....


[   37.397298] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[   37.397358] uvesafb: vbe_init() failed with -22
[   37.397411] uvesafb: probe of uvesafb.0 failed with error -22


....

Here some infos I got with read-edid[1] tool:


./get-edid: get-edid version 1.4.1

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
        Function supported
        Call successful

        VBE version 300
        VBE string at 0x11110 "NVidia"

VBE/DDC service about to be called
        Report DDC capabilities

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
        Function supported
        Call successful

        Monitor and video card combination does not support DDC1 transfers
        Monitor and video card combination supports DDC2 transfers
        0 seconds per 128 byte EDID block transfer
        Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
        Read EDID

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
        Function supported
        Call successful



.....

./parse-edid: parse-edid version 1.4.1
./parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "GD 7000S"
        VendorName "GRC"
        ModelName "GD 7000S"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        HorizSync 30-83
        VertRefresh 50-75
        # Max dot clock (video bandwidth) 140 MHz
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

        Mode    "1280x1024"     # vfreq 60.013Hz, hfreq 63.974kHz
                DotClock        108.500000
                HTimings        1280 1344 1472 1696
                VTimings        1024 1025 1028 1066
                Flags   "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
EndSection

...

Let me know if you need more infos.

Regards,

Gabriel C

[1] http://john.fremlin.de/programs/linux/read-edid/


PS: You have an typo on line 702 in the patch from your website 
s/vesafb/uvesafb/ in that printk

Gabriel C wrote:

Michal Januszewski wrote:
  

quoted

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

  
    

[ .. ]

quoted

I've just tested uvesafb on my workstation ( which has a really old 
GeForce2 MX 400 Nvidia card ) and it didn't worked here.

If I remember right vesafb-ntg worked here and vesafb works for sure :)

Here the error from dmesg :

....


[   37.397298] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[   37.397358] uvesafb: vbe_init() failed with -22
[   37.397411] uvesafb: probe of uvesafb.0 failed with error -22


....
    

Got it to work today with an 2.6.22-rc6-git4 kernel build-in and as 
module and I like it really . good work.

For some reason 2.6.22-rc6 didn't worked here it may have some bug with 
my harware or something ( anyway 2.6.22-rc6-git4 is just fine )

Dmesg from working kernel attached.


Regards,

Gabriel C

I applied
http://dev.gentoo.org/~spock/projects/uvesafb/archive/uvesafb-0.1-rc2-2.6.22-rc6.patchto
2.6.22-rc6-mm1... everything seems to be working properly. However, in dmesg
I did notice the following message:

uvesafb: message too long (9872), can't execute task
uvesafb: VBE get state call failed (eax=0x4f04, err=-7)

The messages seem to get generated when I switch VTs. Just thought I would
let you know. If there is anything else I can do to help let me know.

-Ryan

On 6/30/07, Michal Januszewski [off-list ref] wrote:

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

This is the second version of this patch, and it incorporates all fixes
and cleanups suggested on the lkml.  My thanks to everyone who took
their time to review the first version.

uvesafb uses a userspace helper application (v86d, [2]) to run the x86
Video BIOS code.  This makes it possible to include in uvesafb all the
standard features (refresh rate control, video mode changes etc) that
are missing from vesafb without resorting to ugly hacks such as the ones
used in [1].  The current implementation of v86d can use either LRMI or
x86emu to run the BIOS code and supports both x86 and x86_64.

[1] http://dev.gentoo.org/~spock/projects/vesafb-tng/
[2] http://dev.gentoo.org/~spock/projects/uvesafb/

Best regards.
--
Michal Januszewski                              JID: spock@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

On Thu, Jul 05, 2007 at 01:38:46PM -0400, Ryan Hope wrote:

 I applied
 http://dev.gentoo.org/~spock/projects/uvesafb/archive/uvesafb-0.1-rc2-2.6.22-rc6.patchto
 2.6.22-rc6-mm1... everything seems to be working properly. However, in dmesg
 I did notice the following message:

 uvesafb: message too long (9872), can't execute task
 uvesafb: VBE get state call failed (eax=0x4f04, err=-7)

 The messages seem to get generated when I switch VTs. Just thought I would
 let you know. If there is anything else I can do to help let me know.

It looks like the VBE hardware state buffer for your video card is
larger than the 4k currently supported by connector.  The problem should
be easily fixed by setting CONNECTOR_MAX_MSG_SIZE in include/linux/connector.h
to e.g. 16k.  I've already updated the patch on my website, so next time
you download it, the error messages should be gone.

Best regards,
Michal


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/