Menu
▾
▴
linux-fbdev-devel
|
From: Antonino D. <ad...@po...> - 2003-03-05 08:24:46
|
Hi, I believe it's time to finalize what is needed/not needed for the framebuffer framework: 1. Text mode support? 2. console resizing using fbset (besides stty)? 3. support for unloading of fbcon if modular? 4. driver specified placement of buffers - for putcs method? 5. flexible logo placement/overlayed logo? 6. generic console display rotation? 7. Anything else? 8. feature freeze deadline? If you think any of the above is essential, useful, bloat, etc, please say so. If you think there are features in the present code that needs to be removed, make it known. Tony |
|
From: Geert U. <ge...@li...> - 2003-03-05 09:58:53
|
On 5 Mar 2003, Antonino Daplas wrote:
> I believe it's time to finalize what is needed/not needed for the
> framebuffer framework:
> 1. Text mode support?
Required by at least davem and petr
> 2. console resizing using fbset (besides stty)?
Nice, if it's not too much work.
> 3. support for unloading of fbcon if modular?
> 4. driver specified placement of buffers - for putcs method?
> 5. flexible logo placement/overlayed logo?
> 6. generic console display rotation?
Low priority, IMHO.
> 7. Anything else?
0. Update all drivers
Absolutely required
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: Antonino D. <ad...@po...> - 2003-03-05 12:45:45
|
On Wed, 2003-03-05 at 17:57, Geert Uytterhoeven wrote: > On 5 Mar 2003, Antonino Daplas wrote: > > I believe it's time to finalize what is needed/not needed for the > > framebuffer framework: > > > 1. Text mode support? > > Required by at least davem and petr > > > 2. console resizing using fbset (besides stty)? > > Nice, if it's not too much work. Adding this shouldn't be too hard. > > > 3. support for unloading of fbcon if modular? So we just make fbcon permanently loaded unconditionally? The current code allows 'rmmod fbcon', but it will freeze the system. > 0. Update all drivers > > Absolutely required Yes, which is why we need a feature freeze, so we can spend the rest of the period on driver updating and bug fixing. Tony |
|
From: James S. <jsi...@in...> - 2003-03-05 18:38:51
|
> So we just make fbcon permanently loaded unconditionally? The current > code allows 'rmmod fbcon', but it will freeze the system. Because no other console takes over. This is not a easy problem to solve. Which driver takes over when we switch from one console driver to another. > > Absolutely required > > Yes, which is why we need a feature freeze, so we can spend the rest of > the period on driver updating and bug fixing. I think we pretty much are there. |
|
From: Antonino D. <ad...@po...> - 2003-03-06 01:16:50
|
On Thu, 2003-03-06 at 02:37, James Simmons wrote: > > > So we just make fbcon permanently loaded unconditionally? The current > > code allows 'rmmod fbcon', but it will freeze the system. > > Because no other console takes over. This is not a easy problem to solve. > Which driver takes over when we switch from one console driver to > another. I have already a working fbcon module unloading code in my local copy. The way it works is like this. 1. If take_over_console() is called with the "default" flag clear, it behaves as usual. It takes only a subset of console numbers but "conswitchp" still points to the console driver that was loaded at boot time. 2. If take_over_console() is called with the "default" flag set, it will replace "conswitchp", but the original value of "conswitchp" is saved. 3. If take_over_console() with the "default" flag set is called again, it will fail. It's not logical to just overwrite "conswitchp" over and over again. 4. If give_up_console() is called and if the previous take_over_console() did not overwrite "conswitchp", it proceeds as usual. 5. If give_up_console() is called and if the previous take_over_console() overwrote "conswitchp", give_up_console() will also call take_over_console() but using the saved "conswitchp". I can then load fbdev and fbcon as modules. If I "rmmod fbcon", I get back again to vgacon/dummycon/whatever. I can then load and unload different fbdev's and load fbcon at will. If I want to load mdacon, it will still work on top of fbcon, because mdacon calls take_over_console() with the "default" flag cleared. If you need to load other console drivers, then fbcon must be unloaded first. This is because the rest of the console drivers call take_over_console() with the "default" flag set. I can already load/unload fbcon using vga16fb, rivafb or i810fb as the backend at will. Drivers that wish to allow fbcon unloading can define the xxxfb_release() method. They can choose to save/restore the state (if they have a vga core and running as primary), or just define the xxfb_release method as a dummy (if no vga core or running as secondary). What do you think? Any suggestions to improve this (multiple console drivers for instance)? I would rather have the above, or disallow unloading, than having the whole console system freeze on me. Tony |
|
From: James S. <jsi...@in...> - 2003-03-11 15:57:11
|
> I have already a working fbcon module unloading code in my local copy. > The way it works is like this. > > 1. If take_over_console() is called with the "default" flag clear, it > behaves as usual. It takes only a subset of console numbers but > "conswitchp" still points to the console driver that was loaded at boot > time. > > 2. If take_over_console() is called with the "default" flag set, it will > replace "conswitchp", but the original value of "conswitchp" is saved. > > 3. If take_over_console() with the "default" flag set is called again, > it will fail. It's not logical to just overwrite "conswitchp" over and > over again. > > 4. If give_up_console() is called and if the previous > take_over_console() did not overwrite "conswitchp", it proceeds as > usual. > > 5. If give_up_console() is called and if the previous > take_over_console() overwrote "conswitchp", give_up_console() will also > call take_over_console() but using the saved "conswitchp". > > I can then load fbdev and fbcon as modules. If I "rmmod fbcon", I get > back again to vgacon/dummycon/whatever. I can then load and unload > different fbdev's and load fbcon at will. > > If I want to load mdacon, it will still work on top of fbcon, because > mdacon calls take_over_console() with the "default" flag cleared. > > If you need to load other console drivers, then fbcon must be unloaded > first. This is because the rest of the console drivers call > take_over_console() with the "default" flag set. > > I can already load/unload fbcon using vga16fb, rivafb or i810fb as the > backend at will. Drivers that wish to allow fbcon unloading can define > the xxxfb_release() method. They can choose to save/restore the state > (if they have a vga core and running as primary), or just define the > xxfb_release method as a dummy (if no vga core or running as secondary). > > What do you think? Any suggestions to improve this (multiple console > drivers for instance)? I would rather have the above, or disallow > unloading, than having the whole console system freeze on me. Send me the patch. I like to have this support. As for multiple console support. Well that will just be nasty. Nothing we can do about it. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:35:55
|
> > 1. Text mode support? > > Required by at least davem and petr Just Petr. I'm working to seperate the text code out into a matroxcon.c file. Needs alot more work tho. > > 2. console resizing using fbset (besides stty)? > > Nice, if it's not too much work. :-( I hope to improve fbcon to handle this. > 0. Update all drivers > > Absolutely required Its getting there. Drivers not ported are: 68328fb.c S3triofb.c amifb.c atafb.c clgenfb.c cyber2000fb.c cyberfb.c imsttfb.c <- I have a nearly done driver. The old driver doesn't work on ix86. I tried it. Oh wells. leofb.c pm2fb.c pm3fb.c pvr2fb.c retz3fb.c sun3fb.c valkyriefb.c virgefb.c Many of these drivers have been in state of code rotte for a long time :-( |
|
From: Geert U. <ge...@li...> - 2003-03-05 18:47:52
|
On Wed, 5 Mar 2003, James Simmons wrote:
> > 0. Update all drivers
> >
> > Absolutely required
>
> Its getting there. Drivers not ported are:
>
> 68328fb.c
> S3triofb.c
> amifb.c
You can consider amifb done. I haven't sent it in yet, because I have a few
more cleanups to do.
> atafb.c
This one is tricky, since it needs new copyrect/fillrect/imageblit code for
Atari-style interleaved bitplanes. But since Atari is in a bad shape anyway
it's not that important.
> clgenfb.c
> cyber2000fb.c
> cyberfb.c
> imsttfb.c <- I have a nearly done driver. The old driver doesn't work
> on ix86. I tried it. Oh wells.
> leofb.c
Davem will probably take care of leofb.
> pm2fb.c
> pm3fb.c
> pvr2fb.c
> retz3fb.c
> sun3fb.c
Sun3fb will probably be replaced with the sbuslib stuff Davem wrote for SPARC.
> valkyriefb.c
> virgefb.c
The others cannot be that difficult to port. Most of them are unaccelerated
cfb-style cards.
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: Antonino D. <ad...@po...> - 2003-03-06 01:16:50
|
On Thu, 2003-03-06 at 02:34, James Simmons wrote: > > > > 1. Text mode support? > > > > Required by at least davem and petr > > Just Petr. I'm working to seperate the text code out into a matroxcon.c > file. Needs alot more work tho. > > > > 2. console resizing using fbset (besides stty)? > > > > Nice, if it's not too much work. > > :-( I hope to improve fbcon to handle this. > If you're really against using fbset to resize the console, then the first step is to protect the console from the "dangers" of fbset. Secondly, we can have fbcon_resize() validate the mode instead of just blindly calling fb_set_var(). If it's not valid, then it can also fetch a working mode for it. The user can then fine tune the timings using fbset afterwards. So, do we allow fbcon to handle mode validating and fetching, or do we just leave all this to fbdev? At least let's bring out some ideas on how to go about doing this. Having a working idea, even if dumb, should interest other developers in contributing. Tony |
|
From: James S. <jsi...@in...> - 2003-03-11 15:59:27
|
> Secondly, we can have fbcon_resize() validate the mode instead of just > blindly calling fb_set_var(). If it's not valid, then it can also fetch > a working mode for it. The user can then fine tune the timings using > fbset afterwards. But fb_set_var does call teh check_var routine. That is why a fb_set_var in fbcon_resize instead of just calling the set_par routine. > So, do we allow fbcon to handle mode validating and fetching, or do we > just leave all this to fbdev? At least let's bring out some ideas on how > to go about doing this. Having a working idea, even if dumb, should > interest other developers in contributing. That should be done by the low level driver not fbcon. |
|
From: Carlo E. P. <fl...@fl...> - 2003-03-06 07:04:51
|
Subject: Re: [Linux-fbdev-devel] Feature Freeze? Date: gio, mar 06, 2003 at 09:18:07 +0800 Quoting Antonino Daplas (ad...@po...): > > > > 2. console resizing using fbset (besides stty)? > > > > > > Nice, if it's not too much work. > > > > :-( I hope to improve fbcon to handle this. > > > > If you're really against using fbset to resize the console, then the > first step is to protect the console from the "dangers" of fbset. > Secondly, we can have fbcon_resize() validate the mode instead of just > blindly calling fb_set_var(). If it's not valid, then it can also fetch > a working mode for it. The user can then fine tune the timings using > fbset afterwards. > > > So, do we allow fbcon to handle mode validating and fetching, or do we > just leave all this to fbdev? At least let's bring out some ideas on how > to go about doing this. Having a working idea, even if dumb, should > interest other developers in contributing. I see there currently is much activity on the list. I would like to present the point of view of a heavy framebuffer user: I write multimedia code for artists, and I generally generate video via the framebuffer layer, and trusted old matrox cards (from the Millennium II to the G550). The general process is: - open the framebuffer unit - FBIOGET_VSCREENINFO - change the appropriate values in fb_var_screeninfo - FBIOPUT_VSCREENINFO - mmap - happily write pixels to the memory area This, multiplied for all the video heads that I use within the same program (up to 5 per PC, up to now, *including* the console screen - in this case I control the machine from a network connection). I am especially in need to change the BPP value (often using 16BPP mode), and in a couple of occasions (the latest 2 weeks ago) I had to feed the output of old G200's to large monitors who are only capable of TV resolution. This means setting the framebuffer to 768x576 (PAL) and *interlaced*. The framebuffer model that still survives in 2.4 allows me to obtain all this. I am not much familiar with all the terminology that is used for the new layer. Actually, this framebuffer revolution is what keeps me from enjoying (!) the kernel bleeding edge, as I used to do since almost 10 years ago. Can I poll the list's huge knowledge to find out if and how I can obtain the same result with the new layer? Thanks a lot in advance... Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Antonino D. <ad...@po...> - 2003-03-06 07:53:31
|
On Thu, 2003-03-06 at 15:03, Carlo E. Prelz wrote: > I see there currently is much activity on the list. I would like to > present the point of view of a heavy framebuffer user: I write > multimedia code for artists, and I generally generate video via the > framebuffer layer, and trusted old matrox cards (from the Millennium > II to the G550). The general process is: > > - open the framebuffer unit > - FBIOGET_VSCREENINFO > - change the appropriate values in fb_var_screeninfo > - FBIOPUT_VSCREENINFO > - mmap > - happily write pixels to the memory area All of the above should still work with the 2.5. Care was taken to prevent user application breakage. > > This, multiplied for all the video heads that I use within the same > program (up to 5 per PC, up to now, *including* the console screen - > in this case I control the machine from a network connection). > > I am especially in need to change the BPP value (often using 16BPP > mode), and in a couple of occasions (the latest 2 weeks ago) I had to > feed the output of old G200's to large monitors who are only capable > of TV resolution. This means setting the framebuffer to 768x576 (PAL) > and *interlaced*. The framebuffer model that still survives in 2.4 > allows me to obtain all this. You can still do it for the 2.5, except that the matroxfb is not ported yet. > > I am not much familiar with all the terminology that is used for the > new layer. Actually, this framebuffer revolution is what keeps me from > enjoying (!) the kernel bleeding edge, as I used to do since almost 10 > years ago. > > Can I poll the list's huge knowledge to find out if and how I can > obtain the same result with the new layer? > You still can, in general, use the framebuffer as you would use it in the 2.2.- 2.4 versions. The main difference is console window resizing. As you probably know, in 2.4, resizing was done through the fbdev layer and then the information is transmitted to the console. In 2.5, it is currently the opposite way, from the console to fbdev. The only application that I know of that is able to do that is stty, which in its current incarnation has very limited capability. However, you can still use fbset to change other parameters (color depth, acceleration, etc), anything that will not affect the window size. So the debate really is, should fbset support for console resizing be reimplemented? Or should console resizing through stty be made more powerful, at least to create a video mode that is usable, and then just use fbset later on to fine tune the new video mode? The former is easy, the latter is saner but more difficult to code. The matroxfb on the other hand, is the most complicated fb driver around, so it is perfectly understandable that rewriting the driver for the 2.5 will take some time. Temporarily, you can use Petr's patches until it is ported over to 2.5. ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz The new layer may not produce something tangible in terms of user experience (except perhaps for a faster console), but it should pave the way for better things in the future. Tony |
|
From: Sven L. <lu...@dp...> - 2003-03-05 11:05:53
|
On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > Hi, > > I believe it's time to finalize what is needed/not needed for the > framebuffer framework: > > 1. Text mode support? Would this work also on arches which don't traditionnaly do text mode ? Like ppc for example. > 2. console resizing using fbset (besides stty)? What about dynamic multi-head support ? > 7. Anything else? Well, what is the exact status of mult-head and multi-seat ? It is supposed to work, but i did not (yet) experience it myself, mainly because non of my graphic cards are yet supported. One point i would like to see addressed is the ability to share one framebuffer and have both heads be separate viewports into this same framebuffer. This means setting a framebuffer with a stride equal to the sum of both's head resolution and having each head display a subset of it. This would also include having one head be a mirror of the other and other such things. This feature and resizing may cause problems though. > 8. feature freeze deadline? This would be for fbdev deature freeze, right, not for the drivers ? BTW, i will no more be able to work on pm3fb, since i just recently noticed that my nice AGP8 supporting motherboard doesn't accept my Appian Jeronimo 2000 board. :((( Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2003-03-05 12:45:41
|
On Wed, 2003-03-05 at 19:05, Sven Luther wrote: > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > > > Hi, > > > > I believe it's time to finalize what is needed/not needed for the > > framebuffer framework: > > > > 1. Text mode support? > > Would this work also on arches which don't traditionnaly do text mode ? > Like ppc for example. Yes, pixel-based drawing is still the default. It's only for drivers (matrox and sbus) where it might be needed. > > > 2. console resizing using fbset (besides stty)? > > What about dynamic multi-head support ? > > > 7. Anything else? > > Well, what is the exact status of mult-head and multi-seat ? It is If you mean one card with multiple heads, that will need driver-specific support. > supposed to work, but i did not (yet) experience it myself, mainly > because non of my graphic cards are yet supported. One point i would > like to see addressed is the ability to share one framebuffer and have > both heads be separate viewports into this same framebuffer. This > means setting a framebuffer with a stride equal to the sum of both's > head resolution and having each head display a subset of it. This would > also include having one head be a mirror of the other and other such > things. This feature and resizing may cause problems though. > Because of the massive rewrite, there wasn't really enough time to add major feature sets to the framework. Most of the effort was spent on bug fixing, cleaning up, and speeding up the code (to justify the rewrite). It does have one benefit though, the newer code should make it easier to add an infrastructure on top of fbdev, such as xinerama-style support. But this will be in the future. > > 8. feature freeze deadline? > > This would be for fbdev deature freeze, right, not for the drivers ? > Yes, to give people time to port their drivers. > BTW, i will no more be able to work on pm3fb, since i just recently > noticed that my nice AGP8 supporting motherboard doesn't accept my > Appian Jeronimo 2000 board. :((( > That's too bad :-( Tony |
|
From: Sven L. <lu...@dp...> - 2003-03-05 13:44:21
|
On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote: > On Wed, 2003-03-05 at 19:05, Sven Luther wrote: > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > > > > > Hi, > > > > > > I believe it's time to finalize what is needed/not needed for the > > > framebuffer framework: > > > > > > 1. Text mode support? > > > > Would this work also on arches which don't traditionnaly do text mode ? > > Like ppc for example. > > Yes, pixel-based drawing is still the default. It's only for drivers > (matrox and sbus) where it might be needed. And do you think there is a chance of standard vgacon working on a ppc board ? I have a pegasos powerpc/pop based board, and its OF use a x86 emulator to boot the card into vga textmode. matroxfb is broken on it last i tried, and radeonfb was not uptodate in the kernel that was provided, and i there is problems with other fbdevs also, so it would be nice if it was possible to use vgacon on such hardware, until the fbdevs are fixed, but it is a bit hard to fix things without a working console. > > > 2. console resizing using fbset (besides stty)? > > > > What about dynamic multi-head support ? > > > > > 7. Anything else? > > > > Well, what is the exact status of mult-head and multi-seat ? It is > > If you mean one card with multiple heads, that will need driver-specific > support. I thought that the new API, separating the fbcon layer from the fbdev drivers would add support for this more easily. I guess it would be easy for the Appian Jeronimo 2000 board, which has two permedia3 chips, and thus can be seen as two separate devices. Cards with two ramdacs per chip, like the G400, the later radeon's and most recent cards would need driver level support, that is understandable, but is all there for fbcon to take advantage of it ? What about multi-seat, with two full consoles, with mouse and keyboard for each ? > > supposed to work, but i did not (yet) experience it myself, mainly > > because non of my graphic cards are yet supported. One point i would > > like to see addressed is the ability to share one framebuffer and have > > both heads be separate viewports into this same framebuffer. This > > means setting a framebuffer with a stride equal to the sum of both's > > head resolution and having each head display a subset of it. This would > > also include having one head be a mirror of the other and other such > > things. This feature and resizing may cause problems though. > > > > Because of the massive rewrite, there wasn't really enough time to add > major feature sets to the framework. Most of the effort was spent on > bug fixing, cleaning up, and speeding up the code (to justify the > rewrite). There is discution about this currently in the DRI/xfree86 mailing list, and i am facing this also in my xfree86 driver. Maybe for the next developpment cycle then. I thought that one of the reasons of the rewrite was to provide easier multi-head and multi-seat support though. > It does have one benefit though, the newer code should make it easier to > add an infrastructure on top of fbdev, such as xinerama-style support. > But this will be in the future. Mmm, I don't know if there is really a point to this, are there really all that much applications which do xinerama-like things on top of fbdev ? I rather thought that more higlevel userland apps would be doing this. like either xfree86 with chip-specific drivers or fbdev drivers, or directfb or something such. What i think would be nice is to be able to separate the framebuffer setup (where we write to) from the dac/dp output to the monitors, and when we outport this to the higher level apps, we export them separatedly. This way X drivers can use one huge framebuffer, with DRI enabled to render on the framebuffer, and enable arbitrary setting of viewports into this framebuffer, with eventual scaling or other such stuff. And fbcon could then easily use two viewports into the same framebuffer to do dual-head/dual-seat. Overlays (for cursor and/or video) would be linked to the monitor outputs and not the framebuffer. But maybe it is too late for this, good ideas for 2.7.x/3.1.x or whatever it will be named though, together with a framebuffer/agp memory management scheme which would be common to DRI, fbdev and X, and would reside in the drm module. > > > 8. feature freeze deadline? > > > > This would be for fbdev deature freeze, right, not for the drivers ? > > > > Yes, to give people time to port their drivers. :))) > > BTW, i will no more be able to work on pm3fb, since i just recently > > noticed that my nice AGP8 supporting motherboard doesn't accept my > > Appian Jeronimo 2000 board. :((( > > That's too bad :-( I will see if i get another board someday, but it will not be in the immediate future. And it refused to even boot in the pegasos board. Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2003-03-05 14:06:11
|
On Wed, 5 Mar 2003, Sven Luther wrote:
> On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 19:05, Sven Luther wrote:
> > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote:
> > > > I believe it's time to finalize what is needed/not needed for the
> > > > framebuffer framework:
> > > >
> > > > 1. Text mode support?
> > >
> > > Would this work also on arches which don't traditionnaly do text mode ?
> > > Like ppc for example.
> >
> > Yes, pixel-based drawing is still the default. It's only for drivers
> > (matrox and sbus) where it might be needed.
>
> And do you think there is a chance of standard vgacon working on a ppc
> board ? I have a pegasos powerpc/pop based board, and its OF use a x86
> emulator to boot the card into vga textmode. matroxfb is broken on it
> last i tried, and radeonfb was not uptodate in the kernel that was
> provided, and i there is problems with other fbdevs also, so it
> would be nice if it was possible to use vgacon on such hardware, until
> the fbdevs are fixed, but it is a bit hard to fix things without a
> working console.
If your BIOS initializes your graphics card to VGA text mode, vgacon should
work. The same is true for vga16fb.
Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
a userspace program and vga16fb can be modular.
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: Sven L. <lu...@dp...> - 2003-03-05 14:21:58
|
On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote: > On Wed, 5 Mar 2003, Sven Luther wrote: > > On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote: > > > On Wed, 2003-03-05 at 19:05, Sven Luther wrote: > > > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > > > > I believe it's time to finalize what is needed/not needed for the > > > > > framebuffer framework: > > > > > > > > > > 1. Text mode support? > > > > > > > > Would this work also on arches which don't traditionnaly do text mode ? > > > > Like ppc for example. > > > > > > Yes, pixel-based drawing is still the default. It's only for drivers > > > (matrox and sbus) where it might be needed. > > > > And do you think there is a chance of standard vgacon working on a ppc > > board ? I have a pegasos powerpc/pop based board, and its OF use a x86 > > emulator to boot the card into vga textmode. matroxfb is broken on it > > last i tried, and radeonfb was not uptodate in the kernel that was > > provided, and i there is problems with other fbdevs also, so it > > would be nice if it was possible to use vgacon on such hardware, until > > the fbdevs are fixed, but it is a bit hard to fix things without a > > working console. > > If your BIOS initializes your graphics card to VGA text mode, vgacon should > work. The same is true for vga16fb. It is just a configuration thingy then ? > Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to > initialize the card to textmode. Never tried vgacon, since the BIOS emulator is > a userspace program and vga16fb can be modular. Mmm, but since the emulator is run in OF, this would be ok ? Do you think that vesafb would work also ? Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2003-03-05 14:25:14
|
On Wed, 5 Mar 2003, Sven Luther wrote:
> On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Sven Luther wrote:
> > > On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote:
> > > > On Wed, 2003-03-05 at 19:05, Sven Luther wrote:
> > > > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote:
> > > > > > I believe it's time to finalize what is needed/not needed for the
> > > > > > framebuffer framework:
> > > > > >
> > > > > > 1. Text mode support?
> > > > >
> > > > > Would this work also on arches which don't traditionnaly do text mode ?
> > > > > Like ppc for example.
> > > >
> > > > Yes, pixel-based drawing is still the default. It's only for drivers
> > > > (matrox and sbus) where it might be needed.
> > >
> > > And do you think there is a chance of standard vgacon working on a ppc
> > > board ? I have a pegasos powerpc/pop based board, and its OF use a x86
> > > emulator to boot the card into vga textmode. matroxfb is broken on it
> > > last i tried, and radeonfb was not uptodate in the kernel that was
> > > provided, and i there is problems with other fbdevs also, so it
> > > would be nice if it was possible to use vgacon on such hardware, until
> > > the fbdevs are fixed, but it is a bit hard to fix things without a
> > > working console.
> >
> > If your BIOS initializes your graphics card to VGA text mode, vgacon should
> > work. The same is true for vga16fb.
>
> It is just a configuration thingy then ?
Yes. Enable vgacon, and see what happens...
> > Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
> > initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
> > a userspace program and vga16fb can be modular.
>
> Mmm, but since the emulator is run in OF, this would be ok ?
Yes.
> Do you think that vesafb would work also ?
Vesafb requires the boot loader to make BIOS calls before the kernel is
launched. Can you do that from U-Boot (that's your firmware, right)?
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: Sven L. <lu...@dp...> - 2003-03-05 14:26:30
|
On Wed, Mar 05, 2003 at 03:23:36PM +0100, Geert Uytterhoeven wrote: > On Wed, 5 Mar 2003, Sven Luther wrote: > > On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote: > > > On Wed, 5 Mar 2003, Sven Luther wrote: > > > > On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote: > > > > > On Wed, 2003-03-05 at 19:05, Sven Luther wrote: > > > > > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > > > > > > I believe it's time to finalize what is needed/not needed for the > > > > > > > framebuffer framework: > > > > > > > > > > > > > > 1. Text mode support? > > > > > > > > > > > > Would this work also on arches which don't traditionnaly do text mode ? > > > > > > Like ppc for example. > > > > > > > > > > Yes, pixel-based drawing is still the default. It's only for drivers > > > > > (matrox and sbus) where it might be needed. > > > > > > > > And do you think there is a chance of standard vgacon working on a ppc > > > > board ? I have a pegasos powerpc/pop based board, and its OF use a x86 > > > > emulator to boot the card into vga textmode. matroxfb is broken on it > > > > last i tried, and radeonfb was not uptodate in the kernel that was > > > > provided, and i there is problems with other fbdevs also, so it > > > > would be nice if it was possible to use vgacon on such hardware, until > > > > the fbdevs are fixed, but it is a bit hard to fix things without a > > > > working console. > > > > > > If your BIOS initializes your graphics card to VGA text mode, vgacon should > > > work. The same is true for vga16fb. > > > > It is just a configuration thingy then ? > > Yes. Enable vgacon, and see what happens... Ok, i will try again once i get the board back, but i think i remember that i tried it already, and nothing happened. > > > Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to > > > initialize the card to textmode. Never tried vgacon, since the BIOS emulator is > > > a userspace program and vga16fb can be modular. > > > > Mmm, but since the emulator is run in OF, this would be ok ? > > Yes. > > > Do you think that vesafb would work also ? > > Vesafb requires the boot loader to make BIOS calls before the kernel is > launched. Can you do that from U-Boot (that's your firmware, right)? No, it uses smartfirmware. I will have to look into this more, i am not all that familiar with OF, and the docs i found are not all that easy to get into. Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2003-03-05 14:45:27
|
On Wed, 2003-03-05 at 21:43, Sven Luther wrote: > On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote: > > On Wed, 2003-03-05 at 19:05, Sven Luther wrote: > > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote: > > > > > > > > Hi, > > > > > > > > I believe it's time to finalize what is needed/not needed for the > > > > framebuffer framework: > > > > > > > > 1. Text mode support? > > > > > > Would this work also on arches which don't traditionnaly do text mode ? > > > Like ppc for example. > > > > Yes, pixel-based drawing is still the default. It's only for drivers > > (matrox and sbus) where it might be needed. > > And do you think there is a chance of standard vgacon working on a ppc > board ? I have a pegasos powerpc/pop based board, and its OF use a x86 > emulator to boot the card into vga textmode. matroxfb is broken on it > last i tried, and radeonfb was not uptodate in the kernel that was > provided, and i there is problems with other fbdevs also, so it > would be nice if it was possible to use vgacon on such hardware, until > the fbdevs are fixed, but it is a bit hard to fix things without a > working console. > > > > > 2. console resizing using fbset (besides stty)? > > > > > > What about dynamic multi-head support ? > > > > > > > 7. Anything else? > > > > > > Well, what is the exact status of mult-head and multi-seat ? It is > > > > If you mean one card with multiple heads, that will need driver-specific > > support. > > I thought that the new API, separating the fbcon layer from the fbdev > drivers would add support for this more easily. I guess it would be easy > for the Appian Jeronimo 2000 board, which has two permedia3 chips, and > thus can be seen as two separate devices. Cards with two ramdacs per > chip, like the G400, the later radeon's and most recent cards would need > driver level support, that is understandable, but is all there for fbcon > to take advantage of it ? What about multi-seat, with two full consoles, > with mouse and keyboard for each ? > This was one of the goals of the Ruby project, but I think it's mostly the input layer that got into the kernel. Fbcon needs to be cleaned up, a lot. It still implements the "current console or foreground console" concept (only one console active at a time). Also, this is more of a job for linuxconsole than fbdev. I may be wrong though. > > It does have one benefit though, the newer code should make it easier to > > add an infrastructure on top of fbdev, such as xinerama-style support. > > But this will be in the future. > > Mmm, I don't know if there is really a point to this, are there really > all that much applications which do xinerama-like things on top of fbdev ? > I rather thought that more higlevel userland apps would be doing this. > like either xfree86 with chip-specific drivers or fbdev drivers, or > directfb or something such. > You're right, xinerama is mainly user-app. Tony |
|
From: James S. <jsi...@in...> - 2003-03-05 18:48:02
|
> This was one of the goals of the Ruby project, but I think it's mostly > the input layer that got into the kernel. Also the new fbdev api was apart of ruby. So all the low level changes went in. The upper console layer stuff didn't. This will be for the next developement kernel. > Fbcon needs to be cleaned up, a lot. It still implements the "current > console or foreground console" concept (only one console active at a > time). Also, this is more of a job for linuxconsole than fbdev. I may > be wrong though. Correct. This is more of a console thing. I do want to fix up fbcon now but only for bug fixes. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:54:04
|
> And do you think there is a chance of standard vgacon working on a ppc > board ? I have done some work on vgacon but it needs alot of work. Vgacon is also broken on many platforms. I personally liek to see vgacon independent of the BIOS and more portable. I'm working on this. > I thought that the new API, separating the fbcon layer from the fbdev > drivers would add support for this more easily. You can. I did this because there are embedded devices coming out with two framebuffers. They open like a book and they have two touchscreens but no keybaords. Here VTs make no sense. So you can compile in input support for the touchscreen and just fbdev support. Then just write your app. > What about multi-seat, with two full consoles, > with mouse and keyboard for each ? That requires massive surgery for the console layer. > I thought that one of the reasons of the > rewrite was to provide easier multi-head and multi-seat support though. Its is for the long run. The changes required for this where huge. You had to have one input api. A clean console independent fbdev api. Then you can touch the core console code. When 2.7/3.1 comes around we can add the new console code in. Not much work there then. > What i think would be nice is to be able to separate the framebuffer > setup (where we write to) from the dac/dp output to the monitors, and > when we outport this to the higher level apps, we export them > separatedly. This way X drivers can use one huge framebuffer, with DRI > enabled to render on the framebuffer, and enable arbitrary setting of > viewports into this framebuffer, with eventual scaling or other such > stuff. And fbcon could then easily use two viewports into the same > framebuffer to do dual-head/dual-seat. Overlays (for cursor and/or video) > would be linked to the monitor outputs and not the framebuffer. > > But maybe it is too late for this, good ideas for 2.7.x/3.1.x or > whatever it will be named though, together with a framebuffer/agp memory > management scheme which would be common to DRI, fbdev and X, and would > reside in the drm module. Next developement cycle. This is huge amount of work as well. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:40:39
|
> > > 1. Text mode support? > > > > Would this work also on arches which don't traditionnaly do text mode ? > > Like ppc for example. > > Yes, pixel-based drawing is still the default. It's only for drivers > (matrox and sbus) where it might be needed. Only matrox has true text mode. Well also so did vga16fb but we have vgacon. > It does have one benefit though, the newer code should make it easier to > add an infrastructure on top of fbdev, such as xinerama-style support. > But this will be in the future. So little time. Also I did this so eventually when the DRI/fbdev merger happens it will make life easier for all of us. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:37:21
|
> > 2. console resizing using fbset (besides stty)? > > What about dynamic multi-head support ? Next developement series. > > 8. feature freeze deadline? > > This would be for fbdev deature freeze, right, not for the drivers ? Correct. It pretty much is done. The only thing left to do IMO is cursor cleanup and docs and more buffer handling stuff. |
|
From: Sven L. <lu...@dp...> - 2003-03-05 14:50:09
|
On Wed, Mar 05, 2003 at 10:46:37PM +0800, Antonino Daplas wrote: > > I thought that the new API, separating the fbcon layer from the fbdev > > drivers would add support for this more easily. I guess it would be easy > > for the Appian Jeronimo 2000 board, which has two permedia3 chips, and > > thus can be seen as two separate devices. Cards with two ramdacs per > > chip, like the G400, the later radeon's and most recent cards would need > > driver level support, that is understandable, but is all there for fbcon > > to take advantage of it ? What about multi-seat, with two full consoles, > > with mouse and keyboard for each ? > > > > This was one of the goals of the Ruby project, but I think it's mostly > the input layer that got into the kernel. :((( > Fbcon needs to be cleaned up, a lot. It still implements the "current > console or foreground console" concept (only one console active at a > time). Also, this is more of a job for linuxconsole than fbdev. I may > be wrong though. Mmm, do you know who is working on linuxconsole, and what their plan are ? > > > It does have one benefit though, the newer code should make it easier to > > > add an infrastructure on top of fbdev, such as xinerama-style support. > > > But this will be in the future. > > > > Mmm, I don't know if there is really a point to this, are there really > > all that much applications which do xinerama-like things on top of fbdev ? > > I rather thought that more higlevel userland apps would be doing this. > > like either xfree86 with chip-specific drivers or fbdev drivers, or > > directfb or something such. > > > > You're right, xinerama is mainly user-app. :))) Friendly, Sven Luther |
Thanks for helping keep SourceForge clean.
X