Menu
▾
▴
linux-fbdev-devel
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:24:34
|
On Wed, 2003-03-05 at 22:49, Sven Luther wrote: > 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 ? James also. I think the site is http://linuxconsole.sourceforge.net. Tony |
|
From: James S. <jsi...@in...> - 2003-03-05 18:56:09
|
> > > 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 ? > > James also. I think the site is http://linuxconsole.sourceforge.net. Its me. I have been so busy with fbdev tho I haven't worked on the console project. Plus other events in my life (joblessness) has been keeping me busy doing other things. I have the old ruby code that worked. So it is a matter of porting it over to 2.6 when it comes out. I have been keeping it up to date pretty much (2.5.59). |
|
From: James S. <jsi...@in...> - 2003-03-05 18:30:49
|
> 1. Text mode support? We should remove it. Fbcon is to much bloat for text mode hardware. The only driver that does support a text mode matrox. Sparcs do not support text mode except for promcon. The issue was was a misunderstanding on teh flexiablity of imageblit. The name image blit stirs up this idea of the function has to be a place a image in buffer and send it on it way. This is not the case. Take a look at cg6.c. Fancy tricks are still possible. > 2. console resizing using fbset (besides stty)? Fbcon needs alot of work on this. In theory it shoudl be smart enought to handle the small details. > 3. support for unloading of fbcon if modular? It can be done. I used fbcon modular with MDA text mode. I can test the fbcon driver. The issue is if we have more than one vga card whcih vga to graphics card mapping. > 4. driver specified placement of buffers - for putcs method? Working on this. I think it is possible to merge the tileblit stuff with the new buffer code. > 5. flexible logo placement/overlayed logo? Not so important. More important is fixing fbcon to work with the logo code. You can't compile it right now. > 6. generic console display rotation? Not so important right now. I removed the poll stuff. using signals is better. > 7. Anything else? The cursor code needs cleanup and documentation. > 8. feature freeze deadline? We are very near this. IMO we have two things to work on. The buffer stuff and cleaning up the cursor code. |
|
From: Antonino D. <ad...@po...> - 2003-03-06 01:16:51
|
On Thu, 2003-03-06 at 02:29, James Simmons wrote: > > > 1. Text mode support? > > We should remove it. Fbcon is to much bloat for text mode hardware. The > only driver that does support a text mode matrox. Sparcs do not support > text mode except for promcon. The issue was was a misunderstanding on teh > flexiablity of imageblit. The name image blit stirs up this idea of the > function has to be a place a image in buffer and send it on it way. This > is not the case. Take a look at cg6.c. Fancy tricks are still possible. If you are to add tileblitting, text mode will be inherently supported. > > > 2. console resizing using fbset (besides stty)? > > Fbcon needs alot of work on this. In theory it shoudl be smart enought to > handle the small details. > Any ideas on how to do this? I have one in my other mail. > > 3. support for unloading of fbcon if modular? > > It can be done. I used fbcon modular with MDA text mode. I can test the > fbcon driver. The issue is if we have more than one vga card whcih vga to > graphics card mapping. > See my other mail for a proposal on this. > > 4. driver specified placement of buffers - for putcs method? > > Working on this. I think it is possible to merge the tileblit stuff with > the new buffer code. I have to check your newest patch. > > > 5. flexible logo placement/overlayed logo? > > Not so important. More important is fixing fbcon to work with the logo > code. You can't compile it right now. > > > 6. generic console display rotation? > > Not so important right now. I removed the poll stuff. using signals is > better. Yes, I think so too. > > > 7. Anything else? > > The cursor code needs cleanup and documentation. I already have stuff in my tree where fbcon allocates cursor resources per device. So there's no more static declarations in accel_cursor (and accel_putcs). I can submit that if you want. I also added some locking code for accel_cursor, as well as accel_putcs, just in case thread-safety is indeed an issue. I'm also starting to clean up fbcon_cursor and the vbl_handler. Ideally, they should also be allocated per device so multi-seat can be made possible. It's low-priority right now. Tony |
|
From: James S. <jsi...@in...> - 2003-03-11 16:07:42
|
> If you are to add tileblitting, text mode will be inherently supported. If I do all three tileblitting functions. Personally I think we just need tileblit. > > > 2. console resizing using fbset (besides stty)? > > > > Fbcon needs alot of work on this. In theory it shoudl be smart enought to > > handle the small details. > > > > Any ideas on how to do this? I have one in my other mail. I think it is coming together quite well this last week. > > > 3. support for unloading of fbcon if modular? > > > > It can be done. I used fbcon modular with MDA text mode. I can test the > > fbcon driver. The issue is if we have more than one vga card whcih vga to > > graphics card mapping. > > > > See my other mail for a proposal on this. I will give it a try. > > > 4. driver specified placement of buffers - for putcs method? > > > > Working on this. I think it is possible to merge the tileblit stuff with > > the new buffer code. > > I have to check your newest patch. Its in the BK tree. > > Not so important. More important is fixing fbcon to work with the logo > > code. You can't compile it right now. It works now. It doesn't compile tho if you disable the logo code and havd fbcon set. > > > 6. generic console display rotation? > > > > Not so important right now. I removed the poll stuff. using signals is > > better. > > Yes, I think so too. Actaully the way the pixmap code came out I think we can implement the rotation stuff via the pixmap hooks. > I already have stuff in my tree where fbcon allocates cursor resources > per device. So there's no more static declarations in accel_cursor (and > accel_putcs). I can submit that if you want. I seen it. I added parts. I'm going to use the upper console layer to get ride of the static variables for the cursor stuff. > I also added some locking code for accel_cursor, as well as accel_putcs, > just in case thread-safety is indeed an issue. Added to BK tree already. > I'm also starting to clean up fbcon_cursor and the vbl_handler. > Ideally, they should also be allocated per device so multi-seat can be > made possible. It's low-priority right now. I seen that. The VBL handlers should be removed from fbcon.c and placed in there respected drivers. I think that each driver should register its own VBL handler. Then inside the handler update the cursor. This way all we need is a timer for each display that blinks the cursor. |
Thanks for helping keep SourceForge clean.
X