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

Re: [Linux-fbdev-devel] setcolreg vs. 565

[Benjamin H. <be...@ke...>]

>On Fri, 23 Nov 2001, Benjamin Herrenschmidt wrote:
>> For 5:6:5 things are slightly different since R and B have
>> a 0..31 range while G ranges from 0..63. In the DAC, the ATI
>> chip right-align these, so a given regno is actually split
>> into regno<<3 for R and B values and regno<<2 for G. However,
>> that means we should expose to userland a 64 entries cmap
>> instead of 32, am I wrong ? In this case however, when setting
>> cmap for regno 32..63, we should ignore R and B and only use
>> G, or did I miss something ?
>
>Yes, that's what I did for atyfb (experimental 565 patch which doesn't work
>very well yet :-(

Ok, well, it doesn't quite work yet but I suspect some X brokenness here.

I'll got that fixed in both radeonfb and aty128fb this week-end hopefully.

Ben.

Re: [Linux-fbdev-devel] setcolreg vs. 565

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

On Fri, 23 Nov 2001, Benjamin Herrenschmidt wrote:
> For 5:6:5 things are slightly different since R and B have
> a 0..31 range while G ranges from 0..63. In the DAC, the ATI
> chip right-align these, so a given regno is actually split
> into regno<<3 for R and B values and regno<<2 for G. However,
> that means we should expose to userland a 64 entries cmap
> instead of 32, am I wrong ? In this case however, when setting
> cmap for regno 32..63, we should ignore R and B and only use
> G, or did I miss something ?

Yes, that's what I did for atyfb (experimental 565 patch which doesn't work
very well yet :-(

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] setcolreg vs. 565

[Benjamin H. <be...@ke...>]

While working on radeonfb, I figured out there is something we
probably don't handle properly in it nor in aty128fb, and I'm
actually not sure how we should handle it API-wise with 565.

For 8 bits, 5:5:5 and 24 bits, there is no problem, each
color component has the same size. 8 and 24 bits takes regno
values ranging from 0 to 255, while 5:5:5 takes regno values
ranging from 0 to 31 (internally expanded to 0..255).

For 5:6:5 things are slightly different since R and B have
a 0..31 range while G ranges from 0..63. In the DAC, the ATI
chip right-align these, so a given regno is actually split
into regno<<3 for R and B values and regno<<2 for G. However,
that means we should expose to userland a 64 entries cmap
instead of 32, am I wrong ? In this case however, when setting
cmap for regno 32..63, we should ignore R and B and only use
G, or did I miss something ?

Ben.

[Linux-fbdev-devel] Re: ANNOUNCE ATI 128 port of new api

[Franz S. <Fra...@la...>]

At 02:40 23.11.2001, James Simmons wrote:

> > > I just finished and tested the ATI 128 driver for the ruby tree which 
> uses
> > > the new fbdev api. Works like a charm. No acceleration tho. I will add
> > > that in later. Please give it a try. Also use it as a example for porting
> > > other drivers.
> >
> > I removed some more old PPC cruft (COMPAT_XPMAC, vmode/cmode handling), 
> but I
> > cannot get it to boot, cause it crashes early with a corrupted video 
> mode, so
> > I cannot see anything.
>
>Thanks for removing the crud. I tried the driver on my ix86 box and it
>worked. The only difference is the macmode stuff. Try commenting that out
>to see what happens. If it works then we have a bug with the mac mode
>stuff.

Already tried that, same problem.

> > Have you tried it without any other CONFIG_*_CONSOLE besides
> > CONFIG_FRAMEBUFFER_CONSOLE?
>
>Yes. VGAcon and MDAcon work fine. In fact I run my machine with mdacon and
>fbcon at the same time, with mdacon as my VT console. This way if it oops
>mdacon prints out what happens. Plus I can debug fbcon or a framebuffer
>driver without any problems.

I mean did you try with _only_ CONFIG_FRAMEBUFFER_CONSOLE and 
CONFIG_FB_ATY128 enabled? Cause that's the only choice I have. The screen 
looks like the console code and the chip disagree on the selected 
resolution and/or bpp, but I can't see anything obviously wrong in your 
changes.

Franz.

Re: [Linux-fbdev-devel] Latest atyfb driver?

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

On Thu, 22 Nov 2001, James Simmons wrote:
> > > Where can I find the latest atyfb driver? I like to test out with my ruby
> > > tree.
> > 
> > Merge the one in Linus' tree with the one in the fbdev CVS at SF.
> 
> Tried it out. It didn't work for mach 64 card I have. It is really old. I
> have a 210888GX00 with a spectra DAC 2146886000. So it didn't detect it
> :-(

That's normal. Support for Mach64GX is very limited due to the many choices of
external DACs and clockchips. You could add support for the spectra DAC,
though.

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

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Nick K. <nic...@ma...>]

Hello, Romain!

On Thu, 22 Nov 2001 10:45:29 +0100 you wrote:

> Nick Kurshev wrote:
> 
> > Sorry! This part was taken by me from mga_vid driver
> > and this part is still not clear for me :(
> > IMHO if such branch will be in the Linux this problem
> > will disapeared.
> 
> I don't think bew /dev/ entry with new major will ever
> get integrated, there's been a lot of discussion in LK.
> The idea in linux-console is to add a new FS that would
> allow for such stuff dynamically. But it won't happen
> tomorrow...
> 
As I already wrote - implementing VID driver within framebuffer's one
is not good for me. I need with standalone driver :(
Simply because radeon_vid need with VESA BIOS as graphics server
to get working TV-out.
(radeonfb doesn't enable TV-out and probably will never do that)
> > In the future - it would be better to write into documentation:
> >        __u16 depth_avail;              /* <- available depth(s) for this FOURCC: FB_VIDEOVERLAY_DEPTH* */
> > simply because AFAIK - there are no driver which were implemented with using
> > this standard and first implementation ( of driver and app ) will cause
> > a lot of questions, like: __u16 capability_avail what should be here and so on.
> 
> yes, you're right. It's only a draft :-/
> 
> > These "atoms" exist in X11 project for the same lots of stuff ;)
> > IMHO driver can ingnore unknown fields.
> 
> but you need a way to tell the app that field so-and-so
> are ignored.
> 
It would be better to move such parameters into separate structure
which could be passed into driver through other ioctl (changing
brightness, saturation, ... on the fly). From other side - each
member of this structure is optional for driver.
Maybe it would be even better to pass each such atom as independed
one into driver:

struct hw_video_tuneup
{
  char parameter[40]; // or uint32_t
  uint32_t value;
  uint32_t min_range,max_range;
  uint32_t flags;
};

In the future it ould be possible easy expand this by:
#define BRIGHTNESS 1
#define SATURATION 2
#define HUE        3
/* year after 1-st implementation */
#define SGI_SPECIFIC_PARM123    0xFFFF8888 /* vendor specific addition */

> > P.S.: Maybe it would be better to rename fbvid.h to something other
> > like: linux_video_overlay.h or linux_vid.h
> > Because:
> > framebuffers were designed to get linux console on non x86 systems
> > but it's perfectly other technology and is useful for x86 system too.
> > But: my radeon_vid doesn't require any framebuffer to be loaded and
> > can be loaded from text-mode of x86 systems.
> > I use it over VESA's output driver of mplayer. It's trickly but it's
> > only solution to get working TV-out on radeon chips. Simply because
> > ATI will never open TV-out related documentation due macrovision concerns.
> > But after terminating - VESA will switch display back to text-mode
> > (it's radeon specific thing). If someone will use radeon_vid over
> > framebuffer and tried to use VESA then result will be predictable, imho.
> 
> The new FB layer in linux-console is not dependant on console code,
> you can have console without FB or FB without console. That's was
> the idea behinf fbvid.h : add the ability to overlay video (or
> still image) on the FB, not in the console. if there's also a
> console, fine.
> 
I prefer don't mix framebuffer and video overlay which is useful
on x68 systems too.

> Again, feel free to add this subject to the current discussion
> on the new API in linux-fbdev and linux-console, I think it's
> worth public discussion, as there's obviously interest in
> FB and/or console video. My draft was only a suggestion and
> a way to get the discussion started, not something cast in
> iron that can't be improved/reworked.
> 
Done
> Anyway, radeon stuff interest me a lot, I just bought a
> PowerBook G4 with a radeon mobility M6 in it :-) :-)
> 
Unfortunately - radeon_vid currently is useless for you
simply because only mplayer works with it and only through
VESA. (Currently mplayer is far from standards in console video
overlay stuff :( But I hope that after implementing such standard
it would be possible to add corresponding stuff to mplayer).

> -- 
> DOLBEAU Romain               | Nothing is real but the way that I feel  
> ENS Cachan / Ker Lann        | And I feel like going down, down, down   
> Thesard IRISA / CAPS         |   -- Rainbow,                            
> dol...@cl...    |                 'Self Portrait'
> 


Best regards! Nick

[Linux-fbdev-devel] Re: ANNOUNCE ATI 128 port of new api

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

> > I just finished and tested the ATI 128 driver for the ruby tree which uses
> > the new fbdev api. Works like a charm. No acceleration tho. I will add
> > that in later. Please give it a try. Also use it as a example for porting
> > other drivers.
> 
> I removed some more old PPC cruft (COMPAT_XPMAC, vmode/cmode handling), but I 
> cannot get it to boot, cause it crashes early with a corrupted video mode, so 
> I cannot see anything.

Thanks for removing the crud. I tried the driver on my ix86 box and it
worked. The only difference is the macmode stuff. Try commenting that out
to see what happens. If it works then we have a bug with the mac mode
stuff.

> Have you tried it without any other CONFIG_*_CONSOLE besides 
> CONFIG_FRAMEBUFFER_CONSOLE?

Yes. VGAcon and MDAcon work fine. In fact I run my machine with mdacon and
fbcon at the same time, with mdacon as my VT console. This way if it oops
mdacon prints out what happens. Plus I can debug fbcon or a framebuffer
driver without any problems. 

Re: [Linux-fbdev-devel] Latest atyfb driver?

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

> > Where can I find the latest atyfb driver? I like to test out with my ruby
> > tree.
> 
> Merge the one in Linus' tree with the one in the fbdev CVS at SF.

Tried it out. It didn't work for mach 64 card I have. It is really old. I
have a 210888GX00 with a spectra DAC 2146886000. So it didn't detect it
:-(

[Linux-fbdev-devel] Re: ANNOUNCE ATI 128 port of new api

[Franz S. <Fra...@la...>]

On Wednesday 21 November 2001 01:50, James Simmons wrote:
> I just finished and tested the ATI 128 driver for the ruby tree which uses
> the new fbdev api. Works like a charm. No acceleration tho. I will add
> that in later. Please give it a try. Also use it as a example for porting
> other drivers.

I removed some more old PPC cruft (COMPAT_XPMAC, vmode/cmode handling), but I 
cannot get it to boot, cause it crashes early with a corrupted video mode, so 
I cannot see anything.

Have you tried it without any other CONFIG_*_CONSOLE besides 
CONFIG_FRAMEBUFFER_CONSOLE?

Franz.

Re: [Linux-fbdev-devel] Proper handling of setcolorreg

[Benjamin H. <be...@ke...>]

>I don't know whether XFree86 4.x supports directcolor these days, or
treats it
>like truecolor (with optional gamma table). In the latter case, make sure
>the X
>server sets the ramped colormap.
>
>I remember adding the code for setting the ramped colormap on directcolor to
>3.x XF68_FBDev.

The definition for directcolor exist, however fbdevhw (or the fbdev driver,
I have to check), don't support it.

I verified X properly sent the cmap to the driver, the bug was in radeonfb
switch() function. It had an optim that checked if the source and destination
disp had the same h/zres, bpp, etc... before updating the display. However,
when those were the same, it didn't update the currcon field, thus causing
radeonfb to think X was still console 0 (X change the mode only after
switching to the target console). 

Also, this code should unconditionally set the cmap (or at least if currcon
!= con) instead of setting it only when the resolutio/depth are different.

Finally, radeonfb setcolreg did some weird tricks (aty128fb does too btw)
that I'm considering killing as they more or less force truecolor while
the driver advertise directcolor and I didn't even understand the purpose
of some of them ;)

Ben.

Re: [Linux-fbdev-devel] Proper handling of setcolorreg

[Benjamin H. <be...@ke...>]

>In directcolor mode, there are two possible approaches to emulate console
>colors:
>  - Use a linear ramp as colormap, and write the RGB triplets
corresponding to
>    the console colors into the pixel values.
>  - Store the RGB triples corresponding to the console colors in the
colormap,
>    and set all of R, G and B in the pixel value to the console color index
>    (i.e. the value you'd use in pseudocolor mode).
>
>The second approach has the advantage that you can change the console palette
>without having to redraw the screen, so atyfb uses that.

Ok, so I'm trying to mimmic what atyfb does. Everything seem to work fine
with console and MOL well except 16bpp but I think I know how I broke that),
however, XFree (4.1.0 from latest debian sid) using fbdev seem to never set
the colormap. If I have a console at 8 bpp, X at 24 and MOL at 24, switching
from the console to X gives me an ugly X with what look like console colors
(wrong gamma ramp), but switching from MOL to X gives me correct display
(MOL properly sets it's own cmap). It looks like if X fbdevhw is not touching
the cmap at all like if it expected me to be TRUECOLOR.

Gotta get that dawn X source and look what's up. In any way, I think the
current code in aty128fb (and radeonfb) is broken. I'll redo this based on
your atyfb implementation (except I'll try to keep 15/16 bits support,
MOL need 15 bits while DRI wants 16).

Ben.

[Linux-fbdev-devel] About new API implementation

[<chr...@ph...>]

Hello,

I have written a driver for an ARM embedded system. Due to building constrains, the video memory can only be accessed by writing and reading a 32-bit value. So for word and byte I had to do some masking. So I had to rewrite the fb_{write,read}{b,w} macros
(then a fb memset, fb memcopy functions...)...And in fact nano-X drivers...

But the worst is, actually, if a user program accesses through the mmap memory area to this buffer : the user must use/rewrite the fb_write/read functions.
(maybe I'm not aware of how to do it through the fb driver...it is another problem :-) )

So my question is :
will the new API defines a new structure which contains function pointers to the correct fb_read/write functions (in case of non common r/w functions), like:

struct fb_hw_rw {
void (*fb_writeb) (?? addr, ?? data)
....
}

Moreover if there are two differents fb drivers (I don't know if it is possible in new API), any code thus could use the accurate fb_r/w functions depending on each driver...

Friendly,

Christophe LEVANTIS

Re: [Linux-fbdev-devel] Proper handling of setcolorreg

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

On Thu, 22 Nov 2001, Benjamin Herrenschmidt wrote:
> >In directcolor mode, there are two possible approaches to emulate console
> >colors:
> >  - Use a linear ramp as colormap, and write the RGB triplets
> corresponding to
> >    the console colors into the pixel values.
> >  - Store the RGB triples corresponding to the console colors in the
> colormap,
> >    and set all of R, G and B in the pixel value to the console color index
> >    (i.e. the value you'd use in pseudocolor mode).
> >
> >The second approach has the advantage that you can change the console palette
> >without having to redraw the screen, so atyfb uses that.
> 
> Ok, so I'm trying to mimmic what atyfb does. Everything seem to work fine
> with console and MOL well except 16bpp but I think I know how I broke that),
> however, XFree (4.1.0 from latest debian sid) using fbdev seem to never set
> the colormap. If I have a console at 8 bpp, X at 24 and MOL at 24, switching
> from the console to X gives me an ugly X with what look like console colors
> (wrong gamma ramp), but switching from MOL to X gives me correct display
> (MOL properly sets it's own cmap). It looks like if X fbdevhw is not touching
> the cmap at all like if it expected me to be TRUECOLOR.

I don't know whether XFree86 4.x supports directcolor these days, or treats it
like truecolor (with optional gamma table). In the latter case, make sure the X
server sets the ramped colormap.

I remember adding the code for setting the ramped colormap on directcolor to
3.x XF68_FBDev.

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

Re: [Linux-fbdev-devel] Proper handling of setcolorreg

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

On Thu, 22 Nov 2001 be...@ke... wrote:
> I'm trying to fix some problem with palette/gamma table in radeonfb
> (and possibly aty128fb too), but I'm having trouble figuring out how
> things are supposed to work.
> 
> I've compared what is done in atyfb and aty128fb and it's quite 
> different.
> 
> atyfb unconditionally sets the passed values in the HW registers,
> and then, for color index < 16, sets fbcon_cmap to a linear value
> (regno scaled), not taking into account the passed in rgb value.

In directcolor mode, there are two possible approaches to emulate console
colors:
  - Use a linear ramp as colormap, and write the RGB triplets corresponding to
    the console colors into the pixel values.
  - Store the RGB triples corresponding to the console colors in the colormap,
    and set all of R, G and B in the pixel value to the console color index
    (i.e. the value you'd use in pseudocolor mode).

The second approach has the advantage that you can change the console palette
without having to redraw the screen, so atyfb uses that.

> So here are the questions:
> 
>  - What is the fbcon_cmap.cfbX array supposed to contain ?

It should contain the 16 pixel values corresponding to the 16 console colors,
so fbcon-* knows how to draw pixels in the 16 console colors.

In 2.5.x, the 17th entry will contain the cursor XOR mask.

>  - When using > 8 bit depth, who is supposed to set the linear
>    gamma ramp ? (My understanding is that a client app is responsible
>    to set it's own cmap properly, but it also looks like some apps
>    rely on the default beeing set to a linear gamma ramp). Should
>    I set it this way in set_par by default and then let the app
>    eventually change it ?

If your fbdev claims to be in truecolor mode, your fbdev should do it.
If your fbdev claims to be in directcolor mode, the application should do it
(if the app wants truecolor mode).

>  - When using fbcon (that is no client app), who is responsible
>    for restoring the proper console cmap (in 8 bits) or the linear
>    gamma ramp (in > 8 bits) on console switch ?

If your fbdev claims to be in truecolor mode, your fbdev should do it.

> Note that the TRUECOLOR vs. DIRECTCOLOR distinction isn't really
> mattering here as apparently, the ATI chip always go thru the DAC
> cmap, thus we must always make sure we have a liner gamma ramp
> programmed for > 8 bits modes unless the client app provides it's own
> gamme table.

So ATI always does directcolor mode.

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

Re: [Linux-fbdev-devel] fbgen question

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

jani wrote:

> A short answer will suffice ;)

OMHO, fbgen is the right way because it's a cleaner
way to implement the FB itself, fbgen taking care of
the console stuff.

The main drawback is that multiple console on multiple
fbgen-based driver doesn't work (multiple FB device
work, only console doesn't).

Of coures, other might disagree, and you might want
to check the discussion about a new API proposed
by the linux-console project for 2.5.x.

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

Re: [Linux-fbdev-devel] Latest atyfb driver?

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

On Wed, 21 Nov 2001, James Simmons wrote:
> Where can I find the latest atyfb driver? I like to test out with my ruby
> tree.

Merge the one in Linus' tree with the one in the fbdev CVS at SF.

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] fbgen question

[jani <ja...@as...>]

Hi
is there a preferred way of implementing a low level fb driver for 2.4 when 
it comes to chosing between the fbgen based approach and implementing our own 
fb_ops? AFAIS fbgen was meant to encourage code reuse and simplicity but few 
drivers use it.Is it deprecated or just isn't  a good enough abstraction?
A short answer will suffice ;)
Thanks,
Jani

Re: [Linux-fbdev-devel] fbdev API problems

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

On Thu, 2001-11-22 at 11:23, Sven wrote:
> On Thu, Nov 22, 2001 at 10:32:28AM +0100, Michel D=E4nzer wrote:
> > On Thu, 2001-11-22 at 09:37, Sven wrote:
> >=20
> > > Anyway, even X is not able to do DMA outside of the DRI setup. I woul=
d have
> > > liked it when writing Xv support for the permedia3 chip.
> >=20
> > DMA sure isn't possible without kernel support, but you only need a DRM=
,
> > see a recent version of r128_video.c.
>=20
> Well, and the DRM takes care of security issues, isn't it ?

Yes.

> That said, i don't really have time for playing with X right now, but i a=
m
> aware of the use of DRM for r128. It is linux specific though.

No, it should work on BSD now and on all platforms once the DRM is
ported.


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

[Linux-fbdev-devel] Proper handling of setcolorreg

[<be...@ke...>]

I'm trying to fix some problem with palette/gamma table in radeonfb
(and possibly aty128fb too), but I'm having trouble figuring out how
things are supposed to work.

I've compared what is done in atyfb and aty128fb and it's quite 
different.

atyfb unconditionally sets the passed values in the HW registers,
and then, for color index < 16, sets fbcon_cmap to a linear value
(regno scaled), not taking into account the passed in rgb value.

aty128fb does some weird things depending on the bit depth, and
then do the same thing as atyfb, etc... Additionally, for regno
0 and bpp > 8, it also blast the entire HW cmap with a linear gamma
ramp (which looks more like a workaround than anything else).

radeonfb apparently tries to do something similar to aty128fb but
it's sorta broken giving weird results with both MOL and X fbdev.

So here are the questions:

 - What is the fbcon_cmap.cfbX array supposed to contain ?
 - When using > 8 bit depth, who is supposed to set the linear
   gamma ramp ? (My understanding is that a client app is responsible
   to set it's own cmap properly, but it also looks like some apps
   rely on the default beeing set to a linear gamma ramp). Should
   I set it this way in set_par by default and then let the app
   eventually change it ?
 - When using fbcon (that is no client app), who is responsible
   for restoring the proper console cmap (in 8 bits) or the linear
   gamma ramp (in > 8 bits) on console switch ?

Note that the TRUECOLOR vs. DIRECTCOLOR distinction isn't really
mattering here as apparently, the ATI chip always go thru the DAC
cmap, thus we must always make sure we have a liner gamma ramp
programmed for > 8 bits modes unless the client app provides it's own
gamme table.

Regards,
Ben.

Re: [Linux-fbdev-devel] fbdev API problems

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

On Thu, Nov 22, 2001 at 02:40:00AM -0800, Matt Sottek wrote:
> On Thu, 2001-11-22 at 00:37, Sven wrote:
> > On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote:
> > > >The framebuffer itself is pretty safe to export to userland.
> > > 
> > > I assume you mean to allow people to mmap the framebuffer? Yes this can
> > > usually be safe, but only the screen data. Most chips use graphics
> > > memory of some type for dma command buffers. Most chips cannot safely
> > > give you full access to such memory areas. The sysmem_start and
> > > sysmem_length seem to cover the whole graphics region, not just the
> > > visible framebuffer. This is likely not safe.
> > 
> > DMA is not useable outside of the DRI anyway for now, or do you know of any
> > userland app doing this ?
> > 
> > I guess you need to have root access to the fbdev or something such to be able
> > to do dma, not sure though.
> 
> Yes only the DRI is doing dma. It doesn't matter who is doing it.
> 
> What I was pointing out is that you cannot just let users map the
> "framebuffer" memory (meaning all of the graphics memory) because some
> of that memory may contain active dma command buffers which could be
> hijacked to do insecure things. Like, for instance, blit
> something from system memory into the framebuffer such that you
> can then read it, or write to random areas of memory.

And you can open the fbdev once X has locked it and do mma stuff ?

> > Anyway, even X is not able to do DMA outside of the DRI setup. I would have
> > liked it when writing Xv support for the permedia3 chip.
> > 
> So write a DRM :)

mmm, ...

I was in the process of doing this, mainly for DRI and OpenGL purpose, it
partly exists already anyway, but then RL asserted itself again, and i don't
have the time anymore :((((

Maybe later on ...

Friendly,

Sven Luther
> 
> -Matt
> 
> 

Re: [Linux-fbdev-devel] fbdev API problems

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

On Thu, Nov 22, 2001 at 10:32:28AM +0100, Michel D=E4nzer wrote:
> On Thu, 2001-11-22 at 09:37, Sven wrote:
>=20
> > Anyway, even X is not able to do DMA outside of the DRI setup. I woul=
d have
> > liked it when writing Xv support for the permedia3 chip.
>=20
> DMA sure isn't possible without kernel support, but you only need a DRM=
,
> see a recent version of r128_video.c.

Well, and the DRM takes care of security issues, isn't it ?

That said, i don't really have time for playing with X right now, but i a=
m
aware of the use of DRM for r128. It is linux specific though.

the point was for people misusing the mmio pointer provided by fbdev.

Friendly,

Sven Luther

RE: [Linux-fbdev-devel] fbdev API problems

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

On 22 Nov 2001, Matt Sottek wrote:
> >> Currently mmio and fb pointers are in a PUBLIC data structure, a data
> >> structure that is defined for everyone using the fb interfaces, both
> >> kernel side and user side. 
> 
> >That is so you can do things like use the physical memory address of
> >the framebuffer to display a image from a TV card into it.
> 
> No doubt, as you state, there are applications that would need the
> physical framebuffer address. The problem is that when you just leave
> a pointer laying around in a public data structure there is no way
> for a user application to know when the pointer is valid and when it
> is not. If a unsuspecting TV capture card tried to use my physical
> address without knowing that I only have 64k banks the whole system
> would come down hard.

If it's not safe to use the pointer, set it to NULL and set the size to 0 as
well.

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

Re: [Linux-fbdev-devel] fbdev API problems

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

On Thu, 2001-11-22 at 09:37, Sven wrote:

> Anyway, even X is not able to do DMA outside of the DRI setup. I would ha=
ve
> liked it when writing Xv support for the permedia3 chip.

DMA sure isn't possible without kernel support, but you only need a DRM,
see a recent version of r128_video.c.


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

Re: [Linux-fbdev-devel] fbdev API problems

[Matt S. <mat...@ho...>]

On Thu, 2001-11-22 at 00:37, Sven wrote:
> On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote:
> > >The framebuffer itself is pretty safe to export to userland.
> > 
> > I assume you mean to allow people to mmap the framebuffer? Yes this can
> > usually be safe, but only the screen data. Most chips use graphics
> > memory of some type for dma command buffers. Most chips cannot safely
> > give you full access to such memory areas. The sysmem_start and
> > sysmem_length seem to cover the whole graphics region, not just the
> > visible framebuffer. This is likely not safe.
> 
> DMA is not useable outside of the DRI anyway for now, or do you know of any
> userland app doing this ?
> 
> I guess you need to have root access to the fbdev or something such to be able
> to do dma, not sure though.

Yes only the DRI is doing dma. It doesn't matter who is doing it.

What I was pointing out is that you cannot just let users map the
"framebuffer" memory (meaning all of the graphics memory) because some
of that memory may contain active dma command buffers which could be
hijacked to do insecure things. Like, for instance, blit
something from system memory into the framebuffer such that you
can then read it, or write to random areas of memory.

> 
> Anyway, even X is not able to do DMA outside of the DRI setup. I would have
> liked it when writing Xv support for the permedia3 chip.
> 
So write a DRM :)

-Matt

Re: [Linux-fbdev-devel] fbdev API problems

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

On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote:
> >The framebuffer itself is pretty safe to export to userland.
> 
> I assume you mean to allow people to mmap the framebuffer? Yes this can
> usually be safe, but only the screen data. Most chips use graphics
> memory of some type for dma command buffers. Most chips cannot safely
> give you full access to such memory areas. The sysmem_start and
> sysmem_length seem to cover the whole graphics region, not just the
> visible framebuffer. This is likely not safe.

DMA is not useable outside of the DRI anyway for now, or do you know of any
userland app doing this ?

I guess you need to have root access to the fbdev or something such to be able
to do dma, not sure though.

Anyway, even X is not able to do DMA outside of the DRI setup. I would have
liked it when writing Xv support for the permedia3 chip.

Friendly,

Sven Luther