From: Sven L. <lu...@dp...> - 2001-06-19 10:42:43
|
Hello, ... I have yesterday tested pm3fbs latest incarnation, and have some questions resulting from 2 problems there still are with it. 1) The Console cursor is working fine in depth 15, 16, 32. The blinking cursor is using the revc, which uses a destination inverting blit. But the depth 8 currsor is not working correctly. It shows the right thing when the cursor is blinked away, but when it should be there everything is black. Now, the only difference is that depth 15, 16, 32 (well anything beside 8) is in directcolor, while depth 8 is in CI8 (color index, pseudocolor in fbdev speach). RGB332 could be used to solve this, but somehow i don't think this is the right solution. What i guess happens is that when inverting a pseudocolor framebuffer trough the accel engine, the former color n get's inverted to !n or something such. To solve this, one could simply write the inverted values of colors index 0 to 15 to index 255 to 250. This should work ok for the 16 bit color console, but i guess there are some apps that use the full 256 colors, isn't it ? Mmm, romain, now that i think of it, you could maybe try setting the FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f i think. Could you try this ? But again, altough this solves the 16 color useage, it will not work if you use all 256 colors. And in this case, will the revc function be used ? I simply don't know enough about the whle fbdev scheme to say more here, and thus i ask for advice. 2) Juste after the vgacon -> fbcon switch there is some garbage on the screen that get later scrolled up and disappears (though it remains beside the pengouin logo). This garbage is alternated black and green columns, with some chars in the green columns, which seems to be follow the ascii code, so i guess this may be the font map or something such of the vga text console. Now romain (which don't experience this, since he has powermac) did a cleaning of the whole framebuffer memory at pm3fb initialisation time. No this resulted in a clearing of the screen before the switch, but the garbage still stayed there after the switch. So, where is the right place to do this cleaning, and where do you think this garbage could come from ? Is it a problem that needs to be solved by pm3fb, or a more generic fbdev/fbcon stuff ? Ideally i think fbcon should clear the framebuffer memory before using it. That said, i am not sure about the origin of the stuff, why should it appear, even if we did clean the framebuffer at initialisation time ? does vgacon put it there before being removed ? Or is it the fbcon font map that get's misplaced, or somethign such ? 3) Also in the same vein, what happens when we load/unload pm3fb as a module. Especially, if we manage to revert to vgacon and it's text mode ? Will vgacon restore the fonts and other stuff it needs, or should fbdev save and the nrestore the fonts and stuff, as X does. Hope this was not too long ... Friendly, Sven Luther |
From: Romain D. <do...@ir...> - 2001-06-19 11:25:14
|
Sven LUTHER wrote: > Mmm, romain, now that i think of it, you could maybe try setting the > FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f > i think. Could you try this ? That would indeed invert color #0 to color #15, but is it supposed to be the behavior of _revc ? isn't the inverted #0 another, different color not necessarily defined in the first 16 colors ? 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: Sven L. <lu...@dp...> - 2001-06-19 11:30:20
|
On Tue, Jun 19, 2001 at 01:25:08PM +0200, Romain Dolbeau wrote: > Sven LUTHER wrote: > > > Mmm, romain, now that i think of it, you could maybe try setting the > > FBHardwareWriteMask to only affect the lower 16 bit, this would be 0x0f0f0f0f > > i think. Could you try this ? > > That would indeed invert color #0 to color #15, but is it supposed to be > the behavior of _revc ? isn't the inverted #0 another, different color > not necessarily defined in the first 16 colors ? Don't know, that's why i asked on linux-fbdev, we have to wait for an answer there before doing anything about it. But from what i see, there are only so much solutions to this : 1) use RGB 332 instead of CI8 :((( 2) use the above mentioned fix, and have color #0 inverted to color #15 3) put some inverted colors somewhere else. 4) use hardware cursor 5) don't use accels to do the cursor blinking in depth 8. mmm, this solved nothing. But the writemask solution is a ncie 2 register writes fix, if it works (you have to restore the previous write_mask when you are done, i think, unless you always stay in 16 colors only). What does other card do ? What did pm2fb do ? Friendly, Sven Luther |
From: Romain D. <do...@ir...> - 2001-06-19 11:34:49
|
Sven LUTHER wrote: > 2) use the above mentioned fix, and have color #0 inverted to color #15 > > What does other card do ? What did pm2fb do ? easy answer, I should have looked before: pm2fb use non-accelerated fbcon-cfb8, and this one simply do pixels = (pixels ^ 0x0f0f0f0f). So I guess it is the answer :-) -- 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: Sven L. <lu...@dp...> - 2001-06-19 11:37:51
|
On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote: > Sven LUTHER wrote: > > > 2) use the above mentioned fix, and have color #0 inverted to color #15 > > > > What does other card do ? What did pm2fb do ? > > easy answer, I should have looked before: > > pm2fb use non-accelerated fbcon-cfb8, and this one > simply do pixels = (pixels ^ 0x0f0f0f0f). > > So I guess it is the answer :-) Ok, let's go for this, in wait for a response from the more knowledgeable fbdev gurus ... Friendly, Sven Luther |