linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[James S. <jsi...@tr...>]

> but will you have access to the font drawing accels of fbdev, or should you do
> it by hand ?

No. It is to slow that way. It is better if userland does it itself. Plus
you have code to use inside the kernel.

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Sven L. <lu...@dp...>]

On Fri, Jun 29, 2001 at 12:05:56PM -0700, James Simmons wrote:
> 
> > You are speaking about the merging as something that will happen inevitably,
> > and quite soon also. 
> 
> No. It will be awhile. 
> 
> > How is it really, do the DRI people know you intent to
> > merge the drm and fbdev ? What do they think about it ? I suppose it is quite
> > political stuff, isn't it ?
> 
> I have spoken to them before about this. They know it has to be done but
> don't really care abouot fixing the problem. 
> 
> > What about if an app wants to take over let's say the top 4/3 orsomething such
> > of the screen (in order to open a 16/9 or whatever video playback window or
> > something such) and keep fbcon active in the lower part, in order for the app
> > to do it's I/O ?
> 
> In graphics mode it should draw the fonts itself. Does X use the console
> to draw its fonts? No, of course not. Userland drawing fonts has a few
> advantages as well. One with mmap mmio regions you avoid going threw many
> layers of the console to draw fonts. Second you have much more control
> over the fonts including writing asian fonts which can't be done very well
> in the current console system.

but will you have access to the font drawing accels of fbdev, or should you do
it by hand ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Michel <mic...@ii...>]

Brad Douglas wrote:
> 
> On 22 Jun 2001 02:16:54 +0200, Michel Dänzer wrote:
> >
> >
> > The attached patch significantly enhances the 16 bit handling of aty128fb.
> > I've achieved this mainly by consequently distinguishing between 'depth'
> > and 'bpp'. I've used these terms for the same meanings as in XFree86 4.x;
> > please let me know if you prefer other terms.
> >
> > While this now works perfectly in X for both depth 15 and 16 as well as in
> > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for
> > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette
> > for 565 should have 32 or 64 entries.
> >
> >
> > The patch is against 2.4.5-pre3 from Benjamin Herrenschmidt's tree so the
> > offsets are probably off for Linus' tree.
> >
> >
> > BTW I'd love to work on adding Rage128 and Radeon support to the new
> > atyfb.
> >
> >
> > PS: Ah yes, the patch also fixes panning. :)
> 
> Sorry guys.  I've tried to send that patch to Linus several times without it
> ever being accepted.  I should have been more consistently persistent.

No problem, previous versions of the patch weren't as good as I would have
liked anyway. And Ani is merging it into his tree now.


> My surgery ended up taking 8 hours, but it looks like things went better
> than expected and I'll probably never need a transplant!  Now just to
> recover...

Unfortunately, I don't know what this is about, but I'm sure glad it went
fine, all the best!


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[James S. <jsi...@tr...>]

> > XFree86 is wrong in this department.
> 
> Hmm, XFree86 says you are wrong. ;)

They will find out the hard way :-/

> While I mostly agree for fbcon on Linux, I think this is a strong statement.
> XFree86 tries hard to save and restore video of the VT it runs on. 

Which is also bad. In the future (2.5.X) with the seperation of fbdev from
the console system it will be possible to run /dev/fb without a console. A
console makes no sense on a PDA which lacks a keyboard. I found out the
hardware XFree86 doesn't like this. Well given the year or more
devleopement cycle of XFree86 they will fix about 2003.

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[James S. <jsi...@tr...>]

> You are speaking about the merging as something that will happen inevitably,
> and quite soon also. 

No. It will be awhile. 

> How is it really, do the DRI people know you intent to
> merge the drm and fbdev ? What do they think about it ? I suppose it is quite
> political stuff, isn't it ?

I have spoken to them before about this. They know it has to be done but
don't really care abouot fixing the problem. 

> What about if an app wants to take over let's say the top 4/3 orsomething such
> of the screen (in order to open a 16/9 or whatever video playback window or
> something such) and keep fbcon active in the lower part, in order for the app
> to do it's I/O ?

In graphics mode it should draw the fonts itself. Does X use the console
to draw its fonts? No, of course not. Userland drawing fonts has a few
advantages as well. One with mmap mmio regions you avoid going threw many
layers of the console to draw fonts. Second you have much more control
over the fonts including writing asian fonts which can't be done very well
in the current console system.

> > XFree86 is wrong in this department. The console system should handle it.
> 
> Ah, sure, but Xfree86 is the main app out there, and it is they who really own
> the linux desktop. And they also have the most visibility right now.

So M$ windows owns the PC market. Does this make the way they do software
the right way? In time XFrre86 WILL discover this as linux works across
more and more types of hardware. 

> But again, X actually thinks that they are responsible for handling the card,
> and the DRI follows their lead. It is the X driver who handles the switch
> between the 2D and various 3D contexts. How will using hardware access on the
> console handle this ?

Console will be shutdown in "graphics" mode. This is the way IRIX has
handled it for more than 10 some odd years. It has been proven to work.

[Linux-fbdev-devel] Re: [linux-fbdev] [ANNOUNCE] fbgen "2"

[James S. <jsi...@tr...>]

> I have two problems with this: 
> (1) Please remove ifdef CONFIG_PM around that. pm.h provides dummy
>     pm_* functions when pm is disabled, so you do not have to check
>     CONFIG_PM in driver sources. But if structure does not have this
>     pm_fb field, you must :-(

Okay. I will fix that.

> (2) Is there any reason for having this pointer in this structure at
>     all? Does anybody except driver itself need such thing? You can 
>     have couple of fbdevs pointing to one pm_dev, just because of 
>     they live on same device and cannot be powered up independently.

Yes! 

   One their are devices that need to do more than just blank the screen
for it power management. Take a look at the SA1100 framebuffer driver from
the arm tree. 
   Second we can use the special handler in fb_info to replace the one in
the console. Since their are devices that have special needs we can't
depend on the default console power management function. 
   You made the point about multiple devices. If you have more than one
card of the same type you can use the same call back function. Just pass
different data (struct fb_info) to the pm_register function. This will
allow for different VTs to blank at different time. No would it not suck
if someone left their VT and when it went blank it blanked your head while
you are working. This prevents that. Yes you have to register for each
device to the power management layer. 
   The next case is same card multiple heads. You can have two cases. The
first case is each head can preform its own power management. Easy, treat 
each card as a seperate device. You need a seperate fb_info for each
framebuffer anyways. The final case is where you have multiple heads but
one card and the power management is shared. Again you don't want your
console to go blank because the other one is not being worked on. Again
easy, share the struct pm_dev between each fb_info struct. Just make sure
you have proper locking in this case.   

Re: [Linux-fbdev-devel] Re: [linux-fbdev] [ANNOUNCE] fbgen "2"

[James S. <jsi...@tr...>]

> > > To:             FrameBuffer List <lin...@vu...>
> >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Can somebody tell me which one is current developer list? Or do we have
> > two?
> 
> The SourceForge one.

That is strange. Looking at my address book fbdev list points to the
sourceforge one. I bet my email client at home has the old address. Sorry
about that.

Re: [Linux-fbdev-devel] Re: [linux-fbdev] [ANNOUNCE] fbgen "2"

[Geert U. <ge...@li...>]

On Fri, 29 Jun 2001, Petr Vandrovec wrote:
> On 28 Jun 01 at 16:53, James Simmons wrote:
> > To:             FrameBuffer List <lin...@vu...>
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Can somebody tell me which one is current developer list? Or do we have
> two?

The SourceForge one.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Linux-fbdev-devel] Re: [linux-fbdev] [ANNOUNCE] fbgen "2"

[Petr V. <VAN...@vc...>]

On 28 Jun 01 at 16:53, James Simmons wrote:

> To:             FrameBuffer List <lin...@vu...>
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Can somebody tell me which one is current developer list? Or do we have
two?
                  
> Subject:        [linux-fbdev] [ANNOUNCE] fbgen "2"

> @@ -306,12 +313,16 @@
>     struct fb_monspecs monspecs;         /* Current Monitor specs */
>     struct fb_cmap cmap;                 /* Current cmap */
>     struct fb_ops *fbops;
> +#ifdef CONFIG_PM
> +   struct pm_dev *pm_fb;   
> +#endif   
>     char *screen_base;                   /* Virtual address */
>     struct display *disp;       /* initial display variable */

I have two problems with this: 
(1) Please remove ifdef CONFIG_PM around that. pm.h provides dummy
    pm_* functions when pm is disabled, so you do not have to check
    CONFIG_PM in driver sources. But if structure does not have this
    pm_fb field, you must :-(
(2) Is there any reason for having this pointer in this structure at
    all? Does anybody except driver itself need such thing? You can 
    have couple of fbdevs pointing to one pm_dev, just because of 
    they live on same device and cannot be powered up independently.
                                        Thanks,
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] Aty128fb: Parameters when modularized

[Brad D. <br...@ne...>]

On 27 Jun 2001 22:21:41 +0200, Otto Wyss wrote:
> I've implemented parameters into aty128fb.c when compiled as a module. 
> All seems to work except for the mode parameter. Since this is because 
> modedb.c is not usable for modules, I can't go further. So I'm releasing 
> my patch now in the hope it will just work when modedb.c is usable. It 
> is against a plain 2.4.5 kernel.

You need to make and use your own mode database (or copy the one from
modedb.c) for it to work as a module.  This was done by design.

Brad Douglas
br...@ne...

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Brad D. <br...@ne...>]

On 22 Jun 2001 02:16:54 +0200, Michel D=E4nzer wrote:
>=20
>=20
> The attached patch significantly enhances the 16 bit handling of aty128fb=
.
> I've achieved this mainly by consequently distinguishing between 'depth' =
and
> 'bpp'. I've used these terms for the same meanings as in XFree86 4.x; ple=
ase
> let me know if you prefer other terms.
>=20
> While this now works perfectly in X for both depth 15 and 16 as well as i=
n
> console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for
> fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette =
for
> 565 should have 32 or 64 entries.
>=20
>=20
> The patch is against 2.4.5-pre3 from Benjamin Herrenschmidt's tree so the
> offsets are probably off for Linus' tree.
>=20
>=20
> BTW I'd love to work on adding Rage128 and Radeon support to the new atyf=
b.
>=20
>=20
> PS: Ah yes, the patch also fixes panning. :)

Sorry guys.  I've tried to send that patch to Linus several times without i=
t
ever being accepted.  I should have been more consistently persistent.

PS -

My surgery ended up taking 8 hours, but it looks like things went better th=
an
expected and I'll probably never need a transplant!  Now just to recover...

Brad Douglas
br...@ne...

[Linux-fbdev-devel] [PATCH][2.2 & 2.4] fbgen & multiple RGBA, take 3 (no more MIME)

[Romain D. <do...@ir...>]

James Simmons wrote:

> I will intergrate your changes into my fbgen 2.

Guess that means it's OK to ask for integration.
I repost it with proper inlining (sorry about that)

Description of the patch:

> the attached patch fix a problem with `fbgen' when changing the
> RGBA components but not the depth ; `fbgen' would not change
> the colormap in this case, where it should.
> This patch is for kernel 2.4.x, but can also
> be applied to kernel 2.2.x (same bug, same fix).

#####
--- linux/drivers/video/fbgen.c.ORIG	Thu May 17 14:34:54 2001
+++ linux/drivers/video/fbgen.c	Tue Jun 26 10:26:23 2001
@@ -106,6 +106,7 @@
     struct fb_info_gen *info2 = (struct fb_info_gen *)info;
     int err;
     int oldxres, oldyres, oldbpp, oldxres_virtual, oldyres_virtual,
oldyoffset;
+    struct fb_bitfield oldred, oldgreen, oldblue;
 
     if ((err = fbgen_do_set_var(var, con == currcon, info2)))
 	return err;
@@ -115,12 +116,18 @@
 	oldxres_virtual = fb_display[con].var.xres_virtual;
 	oldyres_virtual = fb_display[con].var.yres_virtual;
 	oldbpp = fb_display[con].var.bits_per_pixel;
+	oldred = fb_display[con].var.red;
+	oldgreen = fb_display[con].var.green;
+	oldblue = fb_display[con].var.blue;
 	oldyoffset = fb_display[con].var.yoffset;
 	fb_display[con].var = *var;
 	if (oldxres != var->xres || oldyres != var->yres ||
 	    oldxres_virtual != var->xres_virtual ||
 	    oldyres_virtual != var->yres_virtual ||
 	    oldbpp != var->bits_per_pixel ||
+	    (!(memcmp(&oldred, &(var->red), sizeof(struct fb_bitfield)))) || 
+	    (!(memcmp(&oldgreen, &(var->green), sizeof(struct fb_bitfield))))
||
+	    (!(memcmp(&oldblue, &(var->blue), sizeof(struct fb_bitfield)))) ||
 	    oldyoffset != var->yoffset) {
 	    fbgen_set_disp(con, info2);
 	    if (info->changevar)
#####


-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Sven L. <lu...@dp...>]

On Wed, Jun 27, 2001 at 11:44:55PM +0200, Michel D=E4nzer wrote:
> Sven LUTHER wrote:
> >=20
> > On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel D=E4nzer wrote:
> > > Sven LUTHER wrote:
> > > > But again, X actually thinks that they are responsible for handli=
ng the
> > > > card, and the DRI follows their lead. It is the X driver who hand=
les the
> > > > switch between the 2D and various 3D contexts.
> > >
> > > That's not correct. In the DRI context, the X server is one of many
> > > clients the DRM mediates hardware access between.
> >=20
> > mmm, but itis the X driver which fournish the register save/restore r=
outins,
> > at least that is how i see it. True it is the drm who calls them, i t=
hink,
> > but still, if you have no X running, i don't know how the save/restor=
e stuff
> > is handled.
>=20
> This is also getting shaky ground for me, but AFAIK each client of the =
DRM is
> responsible to maintain its own context.

At least in the glint driver, in the glint_dri.c function, there is a fun=
ction
called glint_switch_context or something such, which can save and restore=
 both
2D and 3D contextes.

I have not seen any such thing in the openGL/mesa code, but then i did no=
t
look yet much at it.

From what i see, the X glint driver fills in the function in the dRI
structure, and later on, dri/drm can call it when switching context.

> > I suppose you could have any user app initializing the drm with the
> > contec=3Dxt swithc function, but X and drm are very thigly intertwine=
d.
>=20
> There must be special communication between the X server and its client=
s
> because they need to know where the windows are etc.

Yes, but it is much more than that, i have the feeling.

> > Also, it seems the drm modules (or builtins) know really nothing abou=
t the
> > underlaying hardware, it is the X server who tells them where the chi=
p is,
> > and what kind of chip to use.
>=20
> Nope, the DRM finds the chip on its own. Just load the module and watch=
 its
> output.

No, i was able to load the gamma module on a matrox G400 equiped system. =
Am
sure if i provided it with the right values, it would have happily tried =
to
write to the G400 as it was a gamma chip. Have'nt tried though, and could=
 have
missed some identification stuff.

Anyway, the kernel part of the drm is rather dumb. Not much more than dma
handling and interrupt stuff, or so it seems to me.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Michel <mic...@ii...>]

Sven LUTHER wrote:
> 
> On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel Dänzer wrote:
> > Sven LUTHER wrote:
> > > But again, X actually thinks that they are responsible for handling the
> > > card, and the DRI follows their lead. It is the X driver who handles the
> > > switch between the 2D and various 3D contexts.
> >
> > That's not correct. In the DRI context, the X server is one of many
> > clients the DRM mediates hardware access between.
> 
> mmm, but itis the X driver which fournish the register save/restore routins,
> at least that is how i see it. True it is the drm who calls them, i think,
> but still, if you have no X running, i don't know how the save/restore stuff
> is handled.

This is also getting shaky ground for me, but AFAIK each client of the DRM is
responsible to maintain its own context.

> I suppose you could have any user app initializing the drm with the
> contec=xt swithc function, but X and drm are very thigly intertwined.

There must be special communication between the X server and its clients
because they need to know where the windows are etc.

> Also, it seems the drm modules (or builtins) know really nothing about the
> underlaying hardware, it is the X server who tells them where the chip is,
> and what kind of chip to use.

Nope, the DRM finds the chip on its own. Just load the module and watch its
output.


> > > How will using hardware access on the console handle this ?
> >
> > I imagine fbcon would have to be a client of the DRM as well.
> 
> Sure, but will it not conflict with X ? DRI was built with 1 2D client and
> multiple 3d client in mind. I don't think it will run with more than 1 D2
> client right now.

Sure, the status quo is that when switching away from the X VT, the X server
grabs the hardware lock, thus preventing any other client from banging the
hardware. That would have to be changed, which makes this ever happening quite
a bit less probable, given that the console system on other OSs can't do the
same.

At any rate, this will have to be discussed with the major DRI hackers. The
address is dri...@li... . :)


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Sven L. <lu...@dp...>]

On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel D=E4nzer wrote:
> Sven LUTHER wrote:
> > But again, X actually thinks that they are responsible for handling t=
he
> > card, and the DRI follows their lead. It is the X driver who handles =
the
> > switch between the 2D and various 3D contexts.
>=20
> That's not correct. In the DRI context, the X server is one of many cli=
ents
> the DRM mediates hardware access between.

mmm, but itis the X driver which fournish the register save/restore routi=
ns,
at least that is how i see it. True it is the drm who calls them, i think=
, but
still, if you have no X running, i don't know how the save/restore stuff =
is
handled.

I suppose you could have any user app initializing the drm with the conte=
c=3Dxt
swithc function, but X and drm are very thigly intertwined.

Also, it seems the drm modules (or builtins) know really nothing about th=
e
underlaying hardware, it is the X server who tells them where the chip is=
, and
what kind of chip to use.

> > How will using hardware access on the console handle this ?
>=20
> I imagine fbcon would have to be a client of the DRM as well.

Sure, but will it not conflict with X ? DRI was built with 1 2D client an=
d
multiple 3d client in mind. I don't think it will run with more than 1 D2
client right now.

That said, my knowledge is rather fragmentary, it comes from studying the
glint driver (hardly the most advanced DRI support, altough it was the fi=
rst
DRI implementation back then)in hope to find time to implement DRI suppor=
t for
giamma + permedia3 or permedia3 alone.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Michel <mic...@ii...>]

Sven LUTHER wrote:

> > Who better to the knwo the hardware of the console system than the console
> > system itself. As linux is ported to more and more platforms less and less
> > of that graphics hardware will support vga text mode. Even when you place
> > your video card in a vga text mode besides 80x25 XFree86 has a hard time.
> > It makes to many assumptions which end up being wrong. Even without my
> > console changes XFree86 is broken. With my changes it still will be
> > broken. It just in the case of the new console code it reset the mode
> > itself and in the process fix any stupid mistakes XFree86 made.
> 
> yes, fbdev support in linux needs some work, but it can be fixed, if someone
> is willing to do the job.

I seem to be the only one willing to do it. The plan has been evolving in my
head for some time, but I don't feel quite ready to attack it yet. If all else
fails, I'll have to lock myself with just my PowerBook and enough food to
survive into a room for a few days. :)


> But again, X actually thinks that they are responsible for handling the
> card, and the DRI follows their lead. It is the X driver who handles the
> switch between the 2D and various 3D contexts.

That's not correct. In the DRI context, the X server is one of many clients
the DRM mediates hardware access between.

> How will using hardware access on the console handle this ?

I imagine fbcon would have to be a client of the DRM as well.


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Michel <mic...@ii...>]

James Simmons wrote:
> 
> > If i want to do dma with this library, should i need to use the drm, or is
> > some other possibilities available ?
> 
> For now yes. First the fbdev cleanup then the merging of DRI and fbdev.

Now that you had me convinced that using the DRM isn't sensible...

> The merging has to be done very carefully since hardware various quite
> dramatically when going from PDAs to high end rendering farms.

I'm curious how things will work out.


> > Who will be responsible for setting the accel engine in a different state
> > ? as XFree clearly thinks it is his responsability to do such. Or are you
> > thinking only about the new X server ?
> 
> XFree86 is wrong in this department.

Hmm, XFree86 says you are wrong. ;)

> The console system should handle it. Who better to the knwo the hardware of
> the console system than the console system itself. As linux is ported to
> more and more platforms less and less of that graphics hardware will support
> vga text mode. Even when you place your video card in a vga text mode
> besides 80x25 XFree86 has a hard time. It makes to many assumptions which
> end up being wrong. Even without my console changes XFree86 is broken. With
> my changes it still will be broken.

While I mostly agree for fbcon on Linux, I think this is a strong statement.
XFree86 tries hard to save and restore video of the VT it runs on. Granted, it
doesn't always work perfectly, but I'd say it works rather well given the
assumptions it makes and that it doesn't need any OS support.

> It just in the case of the new console code it reset the mode
> itself and in the process fix any stupid mistakes XFree86 made.

I'll also try to make XFree86 use the fbcon interface whenever appropriate.


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Sven L. <lu...@dp...>]

On Wed, Jun 27, 2001 at 09:41:34AM -0700, James Simmons wrote:
> 
> > If i want to do dma with this library, should i need to use the drm, or is
> > some other possibilities available ?
> 
> For now yes. First the fbdev cleanup then the merging of DRI and fbdev.
> The merging has to be done very carefully since hardware various quite
> dramatically when going from PDAs to high end rendering farms. 

You are speaking about the merging as something that will happen inevitably,
and quite soon also. How is it really, do the DRI people know you intent to
merge the drm and fbdev ? What do they think about it ? I suppose it is quite
political stuff, isn't it ?

> > How will a user-space library using the accel engine (it would clearly need a
> > little 'driver' for each chip) cohabit with the acceleration used with fbcon ?
> > 
> > Also i suppose by "graphic" mode you are speaking about X, and by "text" mode,
> > you are speaking about fbcon ?
> 
> Yes. fbcon would shutdown when going into "graphics" mode. This would
> prevent any conflicts.

What about if an app wants to take over let's say the top 4/3 orsomething such
of the screen (in order to open a 16/9 or whatever video playback window or
something such) and keep fbcon active in the lower part, in order for the app
to do it's I/O ?

> > Who will be responsible for setting the accel engine in a different state ? as
> > XFree clearly thinks it is his responsability to do such. Or are you thinking
> > only about the new X server ?
> 
> XFree86 is wrong in this department. The console system should handle it.

Ah, sure, but Xfree86 is the main app out there, and it is they who really own
the linux desktop. And they also have the most visibility right now.

> Who better to the knwo the hardware of the console system than the console
> system itself. As linux is ported to more and more platforms less and less
> of that graphics hardware will support vga text mode. Even when you place
> your video card in a vga text mode besides 80x25 XFree86 has a hard time.
> It makes to many assumptions which end up being wrong. Even without my
> console changes XFree86 is broken. With my changes it still will be
> broken. It just in the case of the new console code it reset the mode
> itself and in the process fix any stupid mistakes XFree86 made.

yes, fbdev support in linux needs some work, but it can be fixed, if someone
is willing to do the job.

But again, X actually thinks that they are responsible for handling the card,
and the DRI follows their lead. It is the X driver who handles the switch
between the 2D and various 3D contexts. How will using hardware access on the
console handle this ?

Ok, i guesss using standard register writing should work without problem, but
what about the dma stuff ? if you use the drm you interact with X.

That said, all this is not really all that clear in my mind right now.

Friendly,

Sven Luther
> 

[Linux-fbdev-devel] Aty128fb: Parameters when modularized

[Otto W. <ott...@bl...>]

I've implemented parameters into aty128fb.c when compiled as a module. 
All seems to work except for the mode parameter. Since this is because 
modedb.c is not usable for modules, I can't go further. So I'm releasing 
my patch now in the hope it will just work when modedb.c is usable. It 
is against a plain 2.4.5 kernel.

O. Wyss

PS. What happens with the patch when I use line wrapping at 72 chars?


--- aty128fb.c.orig	Fri Feb  9 20:30:23 2001
+++ aty128fb.c	Wed Jun 27 20:45:22 2001
@@ -111,7 +111,6 @@
 };
 #endif /* CONFIG_PPC */
 
-#ifndef MODULE
 /* default modedb mode */
 /* 640x480, 60 Hz, Non-Interlaced (25.172 MHz dotclock) */
 static struct fb_videomode defaultmode __initdata = {
@@ -128,7 +127,6 @@
 	sync:		0,
 	vmode:		FB_VMODE_NONINTERLACED
 };
-#endif /* MODULE */
 
 /* struct to hold chip description information */
 struct aty128_chip_info {
@@ -212,12 +210,14 @@
     { 4, 4, 3, 3, 2, 3, 1, 16, 31, 16, "64-bit DDR SGRAM" };
 
 static const char *aty128fb_name = "ATY Rage128";
+
 static int  noaccel __initdata = 0;
+static char *font __initdata = NULL;
+static char *mode __initdata = NULL;
+static int  nomtrr __initdata = 0;
 
-#ifndef MODULE
 static const char *mode_option __initdata = NULL;
-#endif
 
 #ifdef CONFIG_PPC
 static int default_vmode __initdata = VMODE_1024_768_60;
@@ -528,7 +528,7 @@
 	}
 
     if (reset)	/* reset engine?? */
-	printk(KERN_DEBUG "aty128fb: PLL write timeout!");
+	printk(KERN_DEBUG "aty128fb: PLL write timeout!\n");
 }
 
 
@@ -1605,7 +1605,6 @@
 }
 
 
-#ifndef MODULE
 int __init
 aty128fb_setup(char *options)
 {
@@ -1663,7 +1662,6 @@
     }
     return 0;
 }
-#endif /* !MODULE */
 
 
     /*
@@ -1691,7 +1689,7 @@
     video_card = (char *)aci->name;
     info->chip_gen = aci->chip_gen;
 
-    printk(KERN_INFO "aty128fb: %s [chip rev 0x%x] ", video_card, chip_rev);
+    printk(KERN_INFO "aty128fb: %s [chip rev 0x%x]\n", video_card, chip_rev);
 
     if (info->vram_size % (1024 * 1024) == 0)
 	printk("%dM %s\n", info->vram_size / (1024*1024), info->mem->name);
@@ -1710,10 +1708,7 @@
     info->fb_info.blank = &aty128fbcon_blank;
     info->fb_info.flags = FBINFO_FLAG_DEFAULT;
 
-#ifdef MODULE
     var = default_var;
-#else
-    memset(&var, 0, sizeof(var));
 #ifdef CONFIG_PPC
     if (_machine == _MACH_Pmac) {
         if (mode_option) {
@@ -1736,7 +1731,6 @@
                           &defaultmode, 8) == 0)
             var = default_var;
     }
-#endif /* MODULE */
 
     if (noaccel)
         var.accel_flags &= ~FB_ACCELF_TEXT;
@@ -2595,13 +2589,43 @@
 };
 #endif
 
 MODULE_AUTHOR("(c)1999-2000 Brad Douglas <br...@ne...>");
 MODULE_DESCRIPTION("FBDev driver for ATI Rage128 / Pro cards");
+MODULE_PARM(noaccel, "i");
+MODULE_PARM_DESC(noaccel, "Disable hardware acceleration (0 or 1=disabled) (default=0)");
+MODULE_PARM(font, "s");
+MODULE_PARM_DESC(font, "Specify one of the compiled-in fonts (default=none)");
+MODULE_PARM(mode, "s");
+MODULE_PARM_DESC(mode, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
+#ifdef CONFIG_MTRR
+MODULE_PARM(nomtrr, "i");
+MODULE_PARM_DESC(nomtrr, "Disable MTRR support (0 or 1=disabled) (default=0)");
+#endif
+#endif /* MODULE */
 
 int __init
 init_module(void)
 {
+    if (noaccel) {
+        noaccel = 1;
+        printk(KERN_INFO "aty128fb: Parameter NOACCEL set\n");
+    }
+    if (font) {
+        strncpy(fontname, font, sizeof(fontname)-1);
+        printk(KERN_INFO "aty128fb: Parameter FONT set to %s\n", font);
+    }
+    if (mode) {
+        mode_option = mode;
+        printk(KERN_INFO "aty128fb: Parameter MODE set to %s\n", mode);
+    }
+#ifdef CONFIG_MTRR
+    if (nomtrr) {
+        mtrr = 0;
+        printk(KERN_INFO "aty128fb: Parameter NOMTRR set\n");
+    }
+#endif
+    
     aty128fb_init();
     return 0;
 }
@@ -2634,4 +2658,3 @@
         kfree(info);
     }
 }
-#endif /* MODULE */

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Scott A M. <sam...@co...>]

I have the impression that some of the card vendors are thinking about
or have started to use DMA in some of their Xservers. 

There is not a common API for access to the DMA...
Will the fbcon and the Xserver be stepping on each others use of DMA?
Or am I looking for an issue that does not exist?


What is driving the need to accelerate the console?


-- 
Scott A. McConnell

Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[James S. <jsi...@tr...>]

> If i want to do dma with this library, should i need to use the drm, or is
> some other possibilities available ?

For now yes. First the fbdev cleanup then the merging of DRI and fbdev.
The merging has to be done very carefully since hardware various quite
dramatically when going from PDAs to high end rendering farms. 

> How will a user-space library using the accel engine (it would clearly need a
> little 'driver' for each chip) cohabit with the acceleration used with fbcon ?
> 
> Also i suppose by "graphic" mode you are speaking about X, and by "text" mode,
> you are speaking about fbcon ?

Yes. fbcon would shutdown when going into "graphics" mode. This would
prevent any conflicts.

> Who will be responsible for setting the accel engine in a different state ? as
> XFree clearly thinks it is his responsability to do such. Or are you thinking
> only about the new X server ?

XFree86 is wrong in this department. The console system should handle it.
Who better to the knwo the hardware of the console system than the console
system itself. As linux is ported to more and more platforms less and less
of that graphics hardware will support vga text mode. Even when you place
your video card in a vga text mode besides 80x25 XFree86 has a hard time.
It makes to many assumptions which end up being wrong. Even without my
console changes XFree86 is broken. With my changes it still will be
broken. It just in the case of the new console code it reset the mode
itself and in the process fix any stupid mistakes XFree86 made.

Re: [Linux-fbdev-devel] New api wrapper.

[James S. <jsi...@tr...>]

> > I assume this is the result of the API change?
> 
> James, ...
> 
> maybe you should include such a little programm using the new API, or
> something such ?

The problem is from a bug in mmap on the mips platform. The "new" api is
internal to the kernel. Userland doesn't see any changes. I will post
fbgen2 today.

Re: [Linux-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

[James S. <jsi...@tr...>]

> The fix wasn't intended for VC switch, but for any change of
> fb_var_screeninfo parameter. Those can happen without VC switching,
> that's exactly what 'fbset' is for.

This I know. I just want to make sure the fix works for both cases.  

> If on your console you do a 'fbset -depth 16 -rgba 5,6,5,0' followed by
> a 'fbset -depth 16 -rgba 5,5,5,1' [1], any driver using fbdev will end
> up with a crazy colormap because it hasn't been reinstalled after the
> RGBA change.
> 
> Hence the need for the fix.

I will intergrate your changes into my fbgen 2.

Re: [Linux-fbdev-devel] New api wrapper.

[Sven L. <lu...@dp...>]

On Tue, Jun 26, 2001 at 01:13:10PM -0700, Scott A McConnell wrote:
> James Simmons wrote:
> 
> >   I have a patch that provides a wrapper for the new api avaliable for
> > download. http://www.transvirtual.com/~jsimmons/newapi.diff.gz. It is
> > quite big. Pretty much it has a second generation of fbgen. Actually I was
> > thinking was if we could actually change fbgen gradually over ot the new
> > api this would be a better approach. I need to work with the people how
> > wrote fbdev using fbgen. So please step forward.
> > 
> 
> I just upgraded to Ralph's Mips 2.4.5 tree.
> 
> My console on fb appears to be working...
> 
> I have a simple program that maps a frame buffer into user space and
> draws an image onto the fb.
> 
> This program worked fine under 2.4.3 however under 2.4.5 the program
> runs but nothing appears on the FB. The memory I am writing to does not
> appear to be the frame buffer.
> 
> I assume this is the result of the API change?

James, ...

maybe you should include such a little programm using the new API, or
something such ?

Friendly

Sven Luther

Re: [Linux-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

[<dol...@cl...>]

Romain Dolbeau wrote:

> If on your console you do a 'fbset -depth 16 -rgba 5,6,5,0' followed by
> a 'fbset -depth 16 -rgba 5,5,5,1' [1], any driver using fbdev will end
                                                         ^^^^^^^^
That should have been 'fbgen', sorry for the momentary lapse of reason
and the waste of bandwith.

> up with a crazy colormap because it hasn't been reinstalled after the
> RGBA change.

-- 
DOLBEAU Romain               | The Gods made Heavy Metal
ENS Cachan / Ker Lann        |     and it's never gonna die
Thesard IRISA / CAPS         |           -- Manowar
dol...@cl...    | in 'The Gods made Heavy Metal'