Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michel <mic...@ii...> - 2001-07-12 17:18:49
|
James Simmons wrote: > > > >In 2.5.x, we will change behavior: only one app can open /dev/fb* at the > > >same time, and VC switching is adisabled as long as /dev/fb* is open. > > > > This can be a problem. For example, X will open /dev/fb*, so I won't > > be able to open it from my command line tool to send it the ioctl that > > control the mirroring on the VGA output. > > Shouldn't Xinerma be handling that. If it doesn't then as usual XFree86 is > broken. I rather suspect your knowledge about Xinerama is lacking... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-07-12 17:12:07
|
> >In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same > >time, and VC switching is adisabled as long as /dev/fb* is open. > > This can be a problem. For example, X will open /dev/fb*, so I won't > be able to open it from my command line tool to send it the ioctl that > control the mirroring on the VGA output. Shouldn't Xinerma be handling that. If it doesn't then as usual XFree86 is broken. As for multiple access issues this is a huge topic. I plan to hold off until 2.5.X and when I start working on the framebuffer filesystem. Here we can have multiple files where each on can represent a specific type of functionality. With this we can control which functionality can be used by only one process at a time versus functionality that can be managed between multiple process. |
|
From: Geert U. <ge...@li...> - 2001-07-12 14:31:49
|
On Thu, 12 Jul 2001, Scott A McConnell wrote:
> Geert Uytterhoeven wrote:
> > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
> > time, and VC switching is adisabled as long as /dev/fb* is open.
>
> I do not understand...
>
> How will a user that is running a VC on /dev/fb start an application
> that uses the frame buffer? The VC will all ready have the device open?
The user just opens /dev/fb*. The VC subsystem doesn't really `open' /dev/fb*.
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
|
|
From: Scott A M. <sam...@co...> - 2001-07-12 13:28:33
|
Geert Uytterhoeven wrote: > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same > time, and VC switching is adisabled as long as /dev/fb* is open. I do not understand... How will a user that is running a VC on /dev/fb start an application that uses the frame buffer? The VC will all ready have the device open? Scott |
|
From: Romain D. <do...@ir...> - 2001-07-12 12:42:17
|
Michel D=E4nzer wrote: > Nope, X just closes /dev/fb in fbdevHWLeaveVT() ... Chicken and egg. You can switch VT if you've closed fbdev, and upon changing VT you close fbdev... Or is there any way to call fbdevHWLeaveVT _before_ changing VT ? --=20 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 |
|
From: Geert U. <ge...@li...> - 2001-07-12 12:40:45
|
On Thu, 12 Jul 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
> > time, and VC switching is adisabled as long as /dev/fb* is open.
>
> So, XFree86-4 open /dev/fb to use the framebuffer, you
> can't go back to a VC until you have exited X ?
> Looks like a big backward step to me. But of course
> it solves a _lot_ of problems :-)
No. You can still receive a signal when the user wants to switch VC.
In fact this is what X already does, but explicitly: it requests a new VC,
switches to it, disables VC switching, and installs a VC switching signal
handler. When the user wants to switch VCs, X gets the signal, unmaps graphics,
restores to text mode, and switches to the new VC.
So the only thing that changes is that VC switching is implicitly disabled when
/dev/fb* is opened.
> Also, if all VC are on FB0, what happen if you mmap() FB1 ?
> Does it blocks VC switching or not ?
Of course opening /dev/fbX affects VCs tied to fbX only.
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
|
|
From: Michel <mic...@ii...> - 2001-07-12 12:38:25
|
Romain Dolbeau wrote: > > Geert Uytterhoeven wrote: > > > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the > > same time, and VC switching is adisabled as long as /dev/fb* is open. > > So, XFree86-4 open /dev/fb to use the framebuffer, you > can't go back to a VC until you have exited X ? Nope, X just closes /dev/fb in fbdevHWLeaveVT() ... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Benjamin H. <be...@ke...> - 2001-07-12 12:36:21
|
> >In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same >time, and VC switching is adisabled as long as /dev/fb* is open. This can be a problem. For example, X will open /dev/fb*, so I won't be able to open it from my command line tool to send it the ioctl that control the mirroring on the VGA output. |
|
From: Romain D. <do...@ir...> - 2001-07-12 12:32:26
|
Geert Uytterhoeven wrote: > In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same > time, and VC switching is adisabled as long as /dev/fb* is open. So, XFree86-4 open /dev/fb to use the framebuffer, you can't go back to a VC until you have exited X ? Looks like a big backward step to me. But of course it solves a _lot_ of problems :-) Also, if all VC are on FB0, what happen if you mmap() FB1 ? Does it blocks VC switching or not ? -- 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 |
|
From: Geert U. <ge...@li...> - 2001-07-12 12:23:59
|
On Thu, 12 Jul 2001, Romain Dolbeau wrote:
> Gerd Knorr wrote:
> > fb applications have to take care about virtual consoles. They
> > need to know if they running on the foreground vt or not (i.e.
> > if they can draw to the framebuffer or not).
>
> What happen if there's _no_ VT on the FB ?
>
> > If you switch away from the X-Server to a text console you probably
> > don't want the X-Server continue updating the screen because that
> > would f*ck up your terminal.
>
> Yes, that's a problem. Another thing I didn't try: what happen
> if you display a picture on FB1 from a VT0 on FB0, and switch
> to VT1 on FB0. The picture should not be erased on FB1, yes ?
> I'll need to try that.
In 2.5.x, we will change behavior: only one app can open /dev/fb* at the same
time, and VC switching is adisabled as long as /dev/fb* is open.
> > qt-embedded can do that I think (have some window management
> > in place for multiple apps sharing a framebuffer display).
>
> Sven suggested a problem with mmap() ; can 2 apps
> mmap() the framebuffer simultaneously ? If not, then
> there's no need for inter-app resources control. If
> yes...
Will be fixed at the same time :-)
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
|
|
From: Romain D. <do...@ir...> - 2001-07-12 12:03:26
|
Gerd Knorr wrote: > > I had a hacked pm3fb with 8+24 overlay (not video overlay), > > with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi' > > did simply put the picture in the lower 24 bits, anc after a C-c > > the image would stay as an underlay in the console. > ^^^^^^^^^^ > Tried that? Yes, it did in the special 8+24 overlay mode (I don't remember trying in regular 24/32 bpp). Gave me a nice Debian underlay background. Too bad most of the logo is the same color than the fbcon text :-) > fb applications have to take care about virtual consoles. They > need to know if they running on the foreground vt or not (i.e. > if they can draw to the framebuffer or not). What happen if there's _no_ VT on the FB ? > If you switch away from the X-Server to a text console you probably > don't want the X-Server continue updating the screen because that > would f*ck up your terminal. Yes, that's a problem. Another thing I didn't try: what happen if you display a picture on FB1 from a VT0 on FB0, and switch to VT1 on FB0. The picture should not be erased on FB1, yes ? I'll need to try that. > It is still not clear what is supported to happen to any overlays if the > user switches to another virtual console. Will this invalidate any > existing overlays? Note that your fbcon virtual consoles might have > another video mode / color depth / font / ... each, which might also > affect the capabilities of the hardware (ati rage 3d can do yuv overlays > in 16 bpp and more only, but not in 8 bpp ...) My personal belief is that any app should display on the FB if there's no VT or if it is the active VT ; and that upon switching active VT or video mode all state should be assumed lost, i.e. memory buffer are invalid and all overlay are disabled. Say, what happen if a user switch video mode for a VT from another terminal ? (good old telnet :-) Another thing I didn't try yet... > How the overlay memory area can be freed? w/ _FREEBUF :-) > Will the STOP ioctl do that too? Nope, not any longer. An app might want to store picture in 2 or more buffer and start/stop overlay from either one without redisplaying the picture every time. > Ahem. That's a non-trivial problem. We wouldn't discuss the subject if it was trivial, would we ? :-) > qt-embedded can do that I think (have some window management > in place for multiple apps sharing a framebuffer display). Sven suggested a problem with mmap() ; can 2 apps mmap() the framebuffer simultaneously ? If not, then there's no need for inter-app resources control. If yes... > -- > Damn lot people confuse usability and eye-candy. I do :-) -- 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 |
|
From: Gerd K. <kr...@by...> - 2001-07-12 11:40:27
|
> > Don't know anything about the ruby design, but with the current
> > console it simply doesn't work. fbi and fbtv switch the console
> > into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they
> > _have_ to do that for several reasons:
>
> I missing something there. `fbi' doesn't change anything on my
> display except it blanks it before (and after) displaying the
> image.
It doesn't change the video mode by default, yes (there is a switch to
ask for another mode throught). ioctl(tty,KDSETMODE, KD_GRAPHICS) does
not change video modes, but informs the console subsystem that the
application uses the vt for doing graphics. That means fbcon will not
print any text to that vt. console switches do not happen unless the
application allows this.
> I had a hacked pm3fb with 8+24 overlay (not video overlay),
> with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi'
> did simply put the picture in the lower 24 bits, anc after a C-c
> the image would stay as an underlay in the console.
^^^^^^^^^^
Tried that?
> I don't think every app should know what every other app
> do. FBcon use the FB layer, so do `fbi', `fbtv' or whatever.
fb applications have to take care about virtual consoles. They
need to know if they running on the foreground vt or not (i.e.
if they can draw to the framebuffer or not).
If you switch away from the X-Server to a text console you probably
don't want the X-Server continue updating the screen because that
would f*ck up your terminal.
It is still not clear what is supported to happen to any overlays if the
user switches to another virtual console. Will this invalidate any
existing overlays? Note that your fbcon virtual consoles might have
another video mode / color depth / font / ... each, which might also
affect the capabilities of the hardware (ati rage 3d can do yuv overlays
in 16 bpp and more only, but not in 8 bpp ...)
How the overlay memory area can be freed? Will the STOP ioctl do that
too?
> One can have a FB layer _without_ fbcon, say in a multihead
> setup, and that shouldn't prevent any app to run. Simply
> do whatever is required by the user in wherever memory area
> he wants. Every app should be made to behave nicely to other,
> i.e. not overwrite memory it doesn't need unless asked
> otherwise.
Ahem. That's a non-trivial problem. qt-embedded can do that
I think (have some window management in place for multiple apps
sharing a framebuffer display).
Gerd
--
Damn lot people confuse usability and eye-candy.
|
|
From: Sven <lu...@dp...> - 2001-07-12 10:42:49
|
On Thu, Jul 12, 2001 at 11:57:42AM +0200, Romain Dolbeau wrote: > Hello, > > What happens exactly when an app mmap() a /dev/fb* ? > > If the framebuffer is one bunch of linear memory, > you obviously get access to that, starting from > the first byte. > > But what if a framebuffer use 2 discontinuous memory area, > say one for the main framebuffer, one for offscreen stuff > like overlay buffer, Z-buffer, texture... how can an app > access that ? > > Also, when returning the pointer to an offscreen memory > buffer, is it better to give the physical address, > or an offset from the base address of the FB ? my feeling is that you can mmap the whole region of it. Now, i am not sure if it is possible for a second app to mmap the same region, if it is, it could be considered a security problem. I also don't know if it is possible to mmap only a part of the fb memory, in order for a second app to mmap other parts of it. And the memory region are rarely now really dsicontinous, it is just a big memory region which is shared for different values, at least on consumer level boards, which don't have dedicated texture memory or such, like the wildcat boards for example. That said, X handles this by having an offscreen video memory manager and app, whose code you can find under xfree86/common/xf86fbman.c Friendl,y Sven Luther |
|
From: Romain D. <do...@ir...> - 2001-07-12 09:57:47
|
Hello, What happens exactly when an app mmap() a /dev/fb* ? If the framebuffer is one bunch of linear memory, you obviously get access to that, starting from the first byte. But what if a framebuffer use 2 discontinuous memory area, say one for the main framebuffer, one for offscreen stuff like overlay buffer, Z-buffer, texture... how can an app access that ? Also, when returning the pointer to an offscreen memory buffer, is it better to give the physical address, or an offset from the base address of the FB ? TIA -- 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 |
|
From: Romain D. <do...@ir...> - 2001-07-12 09:14:11
|
Hello, A newer, hopefully improved interface for overlay support in the fbdev layer. Any comments and additions welcome, in particular to add support for the color/alpha keying. -- 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 |
|
From: Romain D. <do...@ir...> - 2001-07-12 08:35:37
|
Gerd Knorr wrote: > I'd still think it is better to leave that completely up to the driver > because it's more flexible and gives the driver full control. > paddedX/paddedY will take care about any alignments / paddings and will > probably catch most cases, but there might be other constrains ... OK, I will change to that effect (unless there's someone else that disagree). > Don't know anything about the ruby design, but with the current > console it simply doesn't work. fbi and fbtv switch the console > into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they > _have_ to do that for several reasons: I missing something there. `fbi' doesn't change anything on my display except it blanks it before (and after) displaying the image. I had a hacked pm3fb with 8+24 overlay (not video overlay), with fbcon in the upper 8 bits (CI8) and a 24 bits underlay. `fbi' did simply put the picture in the lower 24 bits, anc after a C-c the image would stay as an underlay in the console. No fancy text mode here... but then I don't do VGA :-) I don't think every app should know what every other app do. FBcon use the FB layer, so do `fbi', `fbtv' or whatever. One can have a FB layer _without_ fbcon, say in a multihead setup, and that shouldn't prevent any app to run. Simply do whatever is required by the user in wherever memory area he wants. Every app should be made to behave nicely to other, i.e. not overwrite memory it doesn't need unless asked otherwise. That way, you can have fbcon using the FB as a console, an image viewer displaying an image anywhere in it, and another app overlaying a picture or video. If a VT is in `text mode', whatever that could be, then obviously you can't use it for graphic display. With my current model it works over pm3fb: I get fbcon to scroll under the overlay without problem (not that the overlay has anything useful in it, _that_ doesn't work yet ;-) -- 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 |
|
From: Geert U. <ge...@li...> - 2001-07-12 07:29:58
|
On Wed, 11 Jul 2001, tea age wrote: > Today I uploaded version 1.07 of i810fb. It contains the i810e patch from > Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor The readme is not accessible. > changes regarding the hint from Geert Uytterhoeven (not all ID's are define > in pci_ids.h!). Then add them to pci_ids.h. If you want your driver to work with or without a newer pci_ids.h, use a scheme like this in your driver: #ifndef DEFINE_THAT_MAY_BE_MISSING #define DEFINE_THAT_MAY_BE_MISSING VALUE #endif > Please, who knows how to put the i180fb source into a public CVS, or better > into the kernel sources, if the licence question is clear. We can put it at http://sourceforge.net/projects/linux-fbdev/. Just register for a SourceForge account and tell James, Brad or me your ID, so we can add you to the project. 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 |
|
From: Gerd K. <kr...@by...> - 2001-07-12 07:15:27
|
> > IMHO it is important to let the driver pick the buffer size to avoid > > trouble due to hardware limitations / alignment issues / ... > > which the application doesn't know about. > > My current idea was the app was told about alignement issue > in _CAP, and could require the size it needs by computing > (pixelsize*paddedX*paddedY), and require that size or more. I'd still think it is better to leave that completely up to the driver because it's more flexible and gives the driver full control. paddedX/paddedY will take care about any alignments / paddings and will probably catch most cases, but there might be other constrains ... > > Hmm, is this _really_ a problem? Do you want to mix that with > > console? I'd expect graphic applications whould use that only, > > like fbtv, dvd players (there is a fb-based one IIRC), ... > > Yes, if you want to be able to use the text console while > displaying stuff like video or a still image. One could > use `fbi' (:-) to display a background picture or `fbtv' > for background movie/video stream. It's an overlay, > it should behave nicely toward the foreground app, > even fbcon. IMHO :-) Don't know anything about the ruby design, but with the current console it simply doesn't work. fbi and fbtv switch the console into graphics mode (ioctl(tty,KDSETMODE, KD_GRAPHICS)). And they _have_ to do that for several reasons: - clean console switching, the apps must not write to the framebuffer if they are not running on the foreground console. fbtv also needs to turn off video DMA before it can allow switching away to another console. - full control over panning. fbcon changing the panning to scroll the text would scroll the fbi image / fbtv video too. fbtv has a switch to keep video dma enabled when switching consoles, this can lead to some funny effects ... Gerd -- Damn lot people confuse usability and eye-candy. |
|
From: tea a. <th...@ag...> - 2001-07-11 19:45:35
|
On Wednesday 11 July 2001 20:02, Sottek, Matthew J wrote: > ... ok > ... Anda just said GNU is fine so please make an > update with the GNU headers in both the *.c and *.h files. >... done as version 1.08. Thomas |
|
From: Ghozlane T. <gt...@pr...> - 2001-07-11 18:23:03
|
----- Original Message ----- From: "James Simmons" <jsi...@tr...> Sent: Wednesday, July 11, 2001 6:02 PM Subject: Re: [Linux-fbdev-devel] insmod framebuffer and console switching. > > I insmod my fb and messages appear on the console but the login prompt > > does not appear. I have to hit enter to get it to show up. > > Look in your /etc/inittab and see if the flag --noclear is passed to > minigetty. Remove that flag to get ride of this behavior. i don't think this is the problem, i have the same issue with 2.2.19 kernal at least : When i insmod my fb driver (i think i saw the same pb with matroxfb) the text printed in the console *before* insmoding is not printed once the fb driver takes control ... I don't know if this is a bug in Scott's (and my) driver, or if this is a limitation of the fb framework ... ghoz |
|
From: Sottek, M. J <mat...@in...> - 2001-07-11 18:02:58
|
(XFree removed from cc list, they probably don't care) I don't think we should use the #defines from pci_ids.h since the don't make any sense. The names are apparently the text off the top of the chip. PCI_VENDER_ID_INTEL should be used, but the rest should be named something correct like PCI_DEVICE_ID_I810E_BRIDGE and PCI_DEVICE_ID_I810E_VGA so we know what is going on. Someone can submit a patch to the kernel for pci_ids.h to make the names sane. This is a chipset, not just a PCI device so I810 doesn't fully describe the part. I have no idea what the MC and IG are in the pci_ids.h names. Maybe the fab? Whatever, they are they are not relevant. >Today I uploaded version 1.07 of i810fb. It contains the >i810e patch from Sottek, Matthew J, (sorry, I rewrote it - >it was buggy) Yea, by chance it worked on the i810e but I obviously lost my train of thought half way through :) >Concerning the issue discussion I like the idea of Jeff >Hartmann. I still think Sottek, Matthew J's solution is >just a workaround. Also I prefer high resolutions on >the console. Well I really don't want the current driver showing up in Linus' tree (I hope it didn't happen already). Something that will not work in the configuration used by 99.9% of the i810 owners is not appropriate for Linus' tree. We need to make a default mode that works for everyone. If you want to continue supporting an additional mode that has high resolutions and acceleration that is fine, but it shouldn't be the default. I just don't think supporting modes greater than 1024x768x256 is necessary for the console, and supporting accelerated fb drivers and X drivers concurrently is just a mess waiting to happen. The easiest thing to do is make the unaccelerated version be the one in the kernel sources, and maintain a patch for acceleration support until we find a clean way for it to work together with XFree, or we discover that it isn't worth the effort. >Please, who knows how to put the i180fb source into a >public CVS, or better into the kernel sources, if the >licence question is clear. Please hold off submitting to Linus until the default mode works with X. Anda just said GNU is fine so please make an update with the GNU headers in both the *.c and *.h files. I'm working on the unaccelerated version now, one that can work for everyone with no other kernel or XFree changes. -Matt |
|
From: Anda M. <a_m...@ho...> - 2001-07-11 17:44:26
|
hi tea age, License is GNU. Muni Reddy Anda >From: tea age <th...@vi...> >To: Jeff Hartmann <jha...@va...>, "Sottek, Matthew J" ><mat...@in...>, Anda MuniReddy ><a_m...@ho...> >CC: Xp...@xf..., "'Lin...@li...'" ><Lin...@li...> >Subject: Re: [Xpert]Re: [Linux-fbdev-devel] On i810/i815 fb issues >Date: Wed, 11 Jul 2001 18:42:56 +0200 > >Concerning the licence I agree from my point of view with GNU. But the >author >of i810fb is Anda MuniReddy. > >Today I uploaded version 1.07 of i810fb. It contains the i810e patch from >Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor >changes regarding the hint from Geert Uytterhoeven (not all ID's are define >in pci_ids.h!). > >Pleas check the following link: > >http://www.visuelle-maschinen.de/ctfb/i810/ > >Concerning the issue discussion I like the idea of Jeff Hartmann. I still >think Sottek, Matthew J's solution is just a workaround. Also I prefer high >resolutions on the console. > >Please, who knows how to put the i180fb source into a public CVS, or better >into the kernel sources, if the licence question is clear. > >Here is some of the discussion again, because not all mails went also to >the >Linux-fbdev-devel list: >----------------------------------------------------------------------------------------------------------------- >Jeff Hartmann wrote: > > > > > The only way to properly solve that is to have some sort of mechanism in > > the Xserver which tells the fbdriver to release agpgart and unbind its > > memory during Xserver initialization. Then at VT switch and Xserver > > close we can call fbdev telling it that it can use the memory again. If > > someone gives me an interface to do this, I will add it to the Xserver > > code. I know nothing about the fbdev API, so if it already has this > > sort of thing, then enlighten me. > > > > I will not make the agpgart driver into a general allocation API, it > > just adds cruft to the kernel, and wastes memory which can not be > > swapped out. Its the wrong solution. Any generalized allocator belongs > > in user space, not in the kernel. > > > >Sottek, Matthew J wrote: > > >>> I've read over some of the discussion of the i810/i815 > >>> framebuffer discussion, and given the code a cursory look. I > >>> currently work for an embedded development group at Intel > >>> and I've been doing X work for quite a while on these > >>> chipsets, so I thought I would jump into the conversation. > >>> > >>> First, looking at the code it seems the main reason this > >>> fb driver hasn't received more support is due to the > >>> competition between X and the fb driver for the gart > >>> resources. Why don't we just make a version of this driver > >>> that makes use of stolen memory only (1MB) and does not use > >>> the ringbuffer. This would give us all modes under 1MB in > >>> size (10x7 at 8bit, 8x6 at 16bit) which is the way the > >>> chipset is supported in all non AGP environments. (OS2, Dos > >>> etc.) This would remove all competition between X and the > >>> fb driver for resources...makes everyone's life easier. > >>> > >Jeff Hartmann wrote: > > >> I think this is also a more then satisfactory solution. > >> Anyone want to > >> implement it? > >Sottek, Matthew J wrote: > > > I'll look at it as soon as I get a spare second. I think the > > current driver is probably pretty close already. > > > > Jeff, do you remember what the current status of the Stolen > > memory is? Do you map it into the Gtt or just leave it alone? > > >Jeff Hartmann wrote: > > > The I810/I815 drivers don't touch stolen memory at this time. > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
|
From: Sven <lu...@dp...> - 2001-07-11 17:13:10
|
On Wed, Jul 11, 2001 at 04:35:07PM +0200, Romain Dolbeau wrote: > > > __u16 blend_factor; /* blending factor */ > > > > add chroma key (rage) here ? > > The problem is, how to handle the mix between the overlay > and the console layer. If the FB doesn't have an alpha > channel (CI8, RGB565), one must use a color key. So one I think that the rage (and maybe mga also from the mga Xv driver) can only support color keyed overlay, not alpha keyed overlay. I think this comes because they use a packed representation anyway (24 bpp), but i could be wrong. > So I simply dodged the problem by saying, we display > the overlay in its area blended (0 to 100%) with > the current display. But we need a better way, > obviously. Yes, we need something better and more open here. Friendly, Sven Luther |
|
From: Sven <lu...@dp...> - 2001-07-11 17:09:53
|
Sorry if i lost older mails regarding this, but i just lost my harddisk here at work yesterday
and just got the replacement today. So i must have lost all incoming mails since monday or such.
On Wed, Jul 11, 2001 at 03:51:07PM +0200, Gerd Knorr wrote:
> > /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */
> > #define FBIOGET_VIDOVERLAY_CAP 0x4620
>
> Better use the _IOR / _IOW / _IOWR macros.
>
> > /* pixel type that can be overlaid */
> > #define FB_VIDOVERLAY_PIXELTYPE_CI8 0x0020
>
> What is this one?
Color Index 8, it is just like the pseudocolor 8bpp used by fbdev. I think maybe we could reuse
the same color indentification as FB use, without the need of FB_VIDOVERLAY stuff ? Or is adding
all the YUV modes there a problem ?
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV422 0x0040
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV444 0x0080
>
> packed pixel or planar? yuv420 should be there too, mpeg decompressed
> gives you planar yuv420.
Packed. Permedia3 don't support planar YUV, but even if the planar to packed unit worked, it would
be done trought the bypass unit. That said i guess other hardware kind support those.
In the Xv driver, i do the planar to packed conversion by hand at copying time. I guess it is not
very heavy, but am not sure, since it happens in the processor and main memory, and don't transit
over the AGP/PCI bus.
That said, you have to provide the source buffer to the Xv putimage function, which does the copying,
but maybe this is not the best way of doing this.
Mmm, my idea on this would have been to provide a user-land library which would contain the driver
thing for every supported card, i thought this was the right way of doing things.
Now, the Xv permedia3 driver uses some standard descriptors for the different supported YUV and co
modes, maybe we should support the same here ?
> > struct fb_vidoverlay_mem {
> > unsigned long omem_start; /* Start of overlay frame buffer mem (phys add) */
> > __u32 omem_len; /* (required) length of overlay frame buffer mem */
> > __u8 n_over; /* number of the overlay buffer to use */
> > };
>
> I'd pass pixeltype + width + height here and let the driver calculate +
> return the image size and scanline length. The driver can easily take
> care about alignment and related issues then.
Yes, the only meaningfull stuff to access memory is the bpp of the source buffer (which can be <>
from the one of the framebuffer), the width and the height of the buffer.
Also, don't forget, most hardware can do buffer flipping. The Permedia3 has 3 VidoOverlay bases. Xv
never uses more than 2 though. Don't know what the 3rd is for, maybe for interlacing ?
> n_over == -1 => "give me any free one" ?
>
> > struct fb_vidoverlay_set {
> > __u32 oxsize; /* overlay size in pixels */
> > __u32 oysize;
> > __u16 pixel_type; /* pixeltype to use */
>
> obviously not needed if every allocated memory area has a width and height
> as suggested above.
As X's offscreen memory manager does.
> > __u16 blend_factor; /* blending factor */
>
> add chroma key (rage) here ?
mmm, Permedia3 can do overlays as follows :
2bit alpha blending, either per pixel (using the alpha value of the pixel) or global. It can
also use keyed overlay, either the alpha channel of the framebuffer, or an RGB key for either the
framebuffer or the overlay source. The third possibility is opaque blending, but not much is needed
for it.
Will we support all of those ? In Xv i support only opaque with mask (using a alpha channel key in
the framebuffer) or globally alpha blended.
Also either filtering or mirroring is possible. You can mirror in X or Y, and filter either only in X
or bilinear.
Friendly,
Sven Luther
|
|
From: tea a. <th...@vi...> - 2001-07-11 16:45:54
|
Concerning the licence I agree from my point of view with GNU. But the author of i810fb is Anda MuniReddy. Today I uploaded version 1.07 of i810fb. It contains the i810e patch from Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor changes regarding the hint from Geert Uytterhoeven (not all ID's are define in pci_ids.h!). Pleas check the following link: http://www.visuelle-maschinen.de/ctfb/i810/ Concerning the issue discussion I like the idea of Jeff Hartmann. I still think Sottek, Matthew J's solution is just a workaround. Also I prefer high resolutions on the console. Please, who knows how to put the i180fb source into a public CVS, or better into the kernel sources, if the licence question is clear. Here is some of the discussion again, because not all mails went also to the Linux-fbdev-devel list: ----------------------------------------------------------------------------------------------------------------- Jeff Hartmann wrote: > > The only way to properly solve that is to have some sort of mechanism in > the Xserver which tells the fbdriver to release agpgart and unbind its > memory during Xserver initialization. Then at VT switch and Xserver > close we can call fbdev telling it that it can use the memory again. If > someone gives me an interface to do this, I will add it to the Xserver > code. I know nothing about the fbdev API, so if it already has this > sort of thing, then enlighten me. > > I will not make the agpgart driver into a general allocation API, it > just adds cruft to the kernel, and wastes memory which can not be > swapped out. Its the wrong solution. Any generalized allocator belongs > in user space, not in the kernel. > Sottek, Matthew J wrote: >>> I've read over some of the discussion of the i810/i815 >>> framebuffer discussion, and given the code a cursory look. I >>> currently work for an embedded development group at Intel >>> and I've been doing X work for quite a while on these >>> chipsets, so I thought I would jump into the conversation. >>> >>> First, looking at the code it seems the main reason this >>> fb driver hasn't received more support is due to the >>> competition between X and the fb driver for the gart >>> resources. Why don't we just make a version of this driver >>> that makes use of stolen memory only (1MB) and does not use >>> the ringbuffer. This would give us all modes under 1MB in >>> size (10x7 at 8bit, 8x6 at 16bit) which is the way the >>> chipset is supported in all non AGP environments. (OS2, Dos >>> etc.) This would remove all competition between X and the >>> fb driver for resources...makes everyone's life easier. >>> Jeff Hartmann wrote: >> I think this is also a more then satisfactory solution. >> Anyone want to >> implement it? Sottek, Matthew J wrote: > I'll look at it as soon as I get a spare second. I think the > current driver is probably pretty close already. > > Jeff, do you remember what the current status of the Stolen > memory is? Do you map it into the Gtt or just leave it alone? Jeff Hartmann wrote: > The I810/I815 drivers don't touch stolen memory at this time. |
754 messages has been excluded from this view by a project administrator.
