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: James S. <jsi...@tr...> - 2001-07-20 17:38:15
|
> what if i make glide use a new VC , a la X, and then pray that userland apps > will play nicely when changing the console, by stopping every write ? > how does fb apps (from X to fbtv) cope with VC switches ? They really don't :-( |
|
From: Olaf H. <ol...@su...> - 2001-07-20 11:42:26
|
On Wed, Jul 18, Andreas Hundt wrote:
> I have a new patch for aty128fb in 2.4.6. It has all of benh's fixes + mine.
> Everyone should be happy with it now. It has both 15 and 16bpp support, does not
> break the gamma ramp feature, etc. Maybe this should be merged in the mainstream
> kernel.
I have reports about the Apple digital displays, the console blank mode
results in funny things, like that:
...
working under the console i took a break
for ±15 min. when i got back my screen looked weird.
my screen was blue-ish with something which looked like lines
left and right of the screen. on the screen was a square (about
1 cm from the border of the screen) outside that square there was
some goldish/blueish blur. and somewhere in the centre of the screen
it looked like some1 spilled some liquid.
the screen went away when i pressed the space-bar.
...
this is with "lcd(adc on a g4/450mp", another one reports something
similar ("funny stripes").
Thats 2.4.2.
Any ideas?
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
|
|
From: Benjamin H. <be...@ke...> - 2001-07-19 10:31:41
|
>I have a new patch for aty128fb in 2.4.6. It has all of benh's fixes + mine. >Everyone should be happy with it now. It has both 15 and 16bpp support, >does not >break the gamma ramp feature, etc. Maybe this should be merged in the >mainstream >kernel. Well, you included my sleep stuffs which is not completely final yet, I'm still cleaning up some rough edges. I'll include your FB_ACTIVATE changes in my tree and post a new patch once I'm happy with the power management. Ben. |
|
From: Matan Ziv-Av <ma...@sv...> - 2001-07-18 20:21:39
|
On Wed, 18 Jul 2001, Andreas Hundt wrote:
> hi,
>
> I have a new patch for aty128fb in 2.4.6. It has all of benh's fixes + mine.
> Everyone should be happy with it now. It has both 15 and 16bpp support, does not
> break the gamma ramp feature, etc. Maybe this should be merged in the mainstream
> kernel.
This part does not make much sense:
@@ -1363,7 +1484,7 @@
aty128_encode_var(var, &par, info);
- if ((var->activate & FB_ACTIVATE_MASK) != FB_ACTIVATE_NOW)
+ if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_TEST)
return 0;
oldxres = display->var.xres;
You call encode_var which sets var->activate to 0, and then test it, so
the test always fails, and FB_ACTIVATE_TEST behaviour is broken both
before and after your patch.
--
Matan Ziv-Av. ma...@sv...
|
|
From: <zh...@pu...> - 2001-07-18 18:42:26
|
Hi, sorry for posting this. but, China banned all sourceforge.net sites recently for reasons i'm still not clear. so i cannot access fbdev's site hosted on sourceforge.net to get myself unsubscribed from this list. also the move of the list to sourceforge.net not long ago(?) seems also messed up with my subscription. so would you please remove me from subscribing? Thanks very much! and sorry again! My subscribing email address is either: zw...@de... OR zh...@pu... OR zh...@us... Really sorry for this distrubing message! And thanks again! |
|
From: Andreas H. <an...@co...> - 2001-07-18 17:30:36
|
hi, I have a new patch for aty128fb in 2.4.6. It has all of benh's fixes + mine. Everyone should be happy with it now. It has both 15 and 16bpp support, does not break the gamma ramp feature, etc. Maybe this should be merged in the mainstream kernel. -- Andreas Hundt an...@co... Convergence Integrated Media GmbH http://www.convergence.de Rosenthaler Str. 51 fon: +49(0)30-72 62 06 50 D-10178 Berlin fax: +49(0)30-72 62 06 55 |
|
From: Romain D. <do...@ir...> - 2001-07-18 14:22:18
|
Petr Vandrovec wrote: > And this is of course wrong. What if you have yoffset = 400, and > now you hit shift-pgup, so yoffset is now 200? So bottom of screen [snip] OK, you were talking about the whole fbcon subsystem while I was talking about the function itself. It's easy to write a function that comply with the specification, but from your description it's obviously difficult to properly use clear_margin :-) Thanks for the answers, -- 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: Petr V. <VAN...@vc...> - 2001-07-18 13:51:06
|
On 18 Jul 01 at 15:25, Romain Dolbeau wrote:
> Petr Vandrovec wrote:
> > It is bug. clear_margin is stupid procedure anyway as
> > it corrupts screen buffer contents, so if you are using
> > non-zero xoffset, you should make sure that there is no
> > right margin...
>
> Why should it corrupts memory ? Properly written,
> you only erase the rows/columns that are displayed
> and not used, i.e.
>
> right margin: from (yoffset)
> to (yoffset + yres)
> and from (conp->vc_cols * fontwidth(p) + xoffset)
> to (xoffset + xres)
I probably do not understand where you are painting black square...
What if you increment xoffset, paint something, and now decrement xoffset,
and increment it back? Now you have vertical black stripe in the middle
of your picture...
> bottom margin: from (xoffset)
> to (xoffset + xres)
> and from (conp->vc_rows * fontheight(p) + yoffset)
> to (yoffset + yres)
And this is of course wrong. What if you have yoffset = 400, and
now you hit shift-pgup, so yoffset is now 200? So bottom of screen
is cleared. Now you cancel viewing scrollback, so yoffset is now back to
400 - and voila, you have black line in the middle of the screen.
fbcon/fbdev has to work hardly around this - it must decide when
to call clear_margin (if it is scrolling caused by console subsystem)
and when not (when you are walking through scrollback).
And even in this case it is buggy. If you'll shift-pgup through whole
framebuffer (of course you has to disable buggy scrollback with
video=scrollback:0, as otherwise software scrollback kicks in and no
ypan is done), you'll find that top line in the framebuffer has cleared
its upper part, because of same area is visible in 'normal' situation as
few lines below last line on the screen. So you have to create one spare
character line between end and top of picture, just to keep this line
black. Another problem is that margin is painted by color #0 and not
by black, so if you'll set bgcolor to red, fill screen with blue,
you'll get blue square with red margin on right/bottom and finally black
around that. It is especially visible with midnight commander, which
sometime has background color set to cyan when clear_margin is invoked.
And as fbcon does not allow xoffset != 0, I do not think that there
is any need for fixing right side of clear_margin.
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Romain D. <do...@ir...> - 2001-07-18 13:25:40
|
Petr Vandrovec wrote:
> It is bug. clear_margin is stupid procedure anyway as
> it corrupts screen buffer contents, so if you are using
> non-zero xoffset, you should make sure that there is no
> right margin...
Why should it corrupts memory ? Properly written,
you only erase the rows/columns that are displayed
and not used, i.e.
right margin: from (yoffset)
to (yoffset + yres)
and from (conp->vc_cols * fontwidth(p) + xoffset)
to (xoffset + xres)
bottom margin: from (xoffset)
to (xoffset + xres)
and from (conp->vc_rows * fontheight(p) + yoffset)
to (yoffset + yres)
and the fbcon-* do it properly except they forgot the xoffset.
--
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: Petr V. <VAN...@vc...> - 2001-07-18 13:09:28
|
On 18 Jul 01 at 14:28, Romain Dolbeau wrote:
> Petr Vandrovec wrote:
>
> > So you should take yoffset/xoffset into account
> > only for setting viewport position (and yres/xres
> > for setting viewport size), while accelerated
> > painting ops should not use these 4 values at all.
>
> OK, thanks. I assume this is _not_ true for
> the clear_margins ? fbcon_cfb32 takes yoffset
> into account, but not xoffset ?!? bug ?
It is bug. clear_margin is stupid procedure anyway as
it corrupts screen buffer contents, so if you are using
non-zero xoffset, you should make sure that there is no
right margin...
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Romain D. <do...@ir...> - 2001-07-18 12:28:34
|
Petr Vandrovec wrote: > So you should take yoffset/xoffset into account > only for setting viewport position (and yres/xres > for setting viewport size), while accelerated > painting ops should not use these 4 values at all. OK, thanks. I assume this is _not_ true for the clear_margins ? fbcon_cfb32 takes yoffset into account, but not xoffset ?!? bug ? 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: Petr V. <VAN...@vc...> - 2001-07-18 12:15:28
|
On 18 Jul 01 at 14:02, Romain Dolbeau wrote:
> In the above functions, are the various position
> parameters (sx, xx, sy, yy) in
>
> 1) display coordinate
> 2) buffer coordinate
>
> Before I commit my change to fix pm3fb, I'd
> like an authoritative answer on the subject.
> It just _feels_ wrong to me to use absolute
> coordinate.
It is buffer coordinate. You have framebuffer
xres_virtual * yres_virtual pixels, and all
coordinates for putc/clear/bmove are relative
to left upper corner of this buffer.
Then you have window xres * yres which specifies
what is visible on screen.
And while coordinates for painting characters
are in character cell, offset from buffer's
top left corner and window top left corner
(xoffset, yoffset) is specified in pixels, not
in character cells.
So you should take yoffset/xoffset into account
only for setting viewport position (and yres/xres
for setting viewport size), while accelerated
painting ops should not use these 4 values at all.
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Romain D. <do...@ir...> - 2001-07-18 12:02:15
|
Hello,
In the above functions, are the various position
parameters (sx, xx, sy, yy) in
1) display coordinate
2) buffer coordinate
if it's 1, then one must take p->var.{x,y}offset
into account when implementing HW acceleration.
that's what pm3fb assume. it doesn't work
apparently (when using yres_virtual > yres,
i.e. using panning)
if it's 2, as apparently is assumed by fbcon_cfb*,
then one can just ignore the offset. it works
for the non-accelerated pm3fb.
Before I commit my change to fix pm3fb, I'd
like an authoritative answer on the subject.
It just _feels_ wrong to me to use absolute
coordinate.
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: Ghozlane T. <gt...@pr...> - 2001-07-18 09:25:38
|
----- Original Message ----- From: "James Simmons" <jsi...@tr...> Subject: Re: [Linux-fbdev-devel] how to drop access to an ioremapped area ? > > I'm looking for a way to somehow "drop" all access to a specific ioremaped > > area , > > for a time , and then "reenable" it .. is there a way to do something like > > that ? > > The best thing you could do right now is just convert the glide > library to use the mmio region of your fbdev device. should be easy, specificaly with the /dev/3dfx device (basicaly if i'm not wrong, it just detects a voodoo board and ioremap the board's mem before giving the info to glide ) > As for access use a > userland lock. Not very secure but it is a hack to get it going. what if i make glide use a new VC , a la X, and then pray that userland apps will play nicely when changing the console, by stopping every write ? how does fb apps (from X to fbtv) cope with VC switches ? ghoz |
|
From: Ollie L. <ol...@si...> - 2001-07-18 01:09:01
|
James Simmons wrote: > > > I'd like to know if there's any active development going on with the sis630 > > fb. I'm no programmer but if I can help with testing patches and stuff, I > > hereby offer my services! :) > > Greetings Jeroen > > I seen another person which I CC also wondering about this. I seen in a > earlier posting someone working on a SiS 6326 driver. I don't know if this > will be of help to you. > 2.4.x kernel has the official framebuffer driver for SiS 630/540. I also has an unofficial sisfb lite driver which I will send to you in another mail. Ollie |
|
From: James S. <jsi...@tr...> - 2001-07-18 00:15:58
|
> I'd like to know if there's any active development going on with the sis630 > fb. I'm no programmer but if I can help with testing patches and stuff, I > hereby offer my services! :) > Greetings Jeroen I seen another person which I CC also wondering about this. I seen in a earlier posting someone working on a SiS 6326 driver. I don't know if this will be of help to you. |
|
From: Nicu P. <pa...@ra...> - 2001-07-17 22:13:39
|
> > > Change LOGO_W and LOGO_H in fbcon.c. > > > > Of course I changed them :) ... when they are just like the image the > > crash occurs ... when they are smaller than the image the kernel doesn't > > crash but the image is trashed. > > Do you have the oops and if you do can you run it threw ksymoops. What > color depth are youo running the console at BTW? > I will try to capture ooops on a serial because is at boot time when kernel try to init i810fb. 16 bits is the color depth. -- ......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::...... - iMedia Linux Senior Developer - -- My favorite music : tcpdump > /dev/dsp -- |
|
From: James S. <jsi...@tr...> - 2001-07-17 22:09:06
|
> I'm looking for a way to somehow "drop" all access to a specific ioremaped > area , > for a time , and then "reenable" it .. is there a way to do something like > that ? This is not at all easy to do. You could write long papers on this subject. The best thingyou could do right now is just convert the glide library to use the mmio region of your fbdev device. As for access use a userland lock. Not very secure but it is a hack to get it going. |
|
From: James S. <jsi...@tr...> - 2001-07-17 16:39:11
|
> > Change LOGO_W and LOGO_H in fbcon.c. > > Of course I changed them :) ... when they are just like the image the > crash occurs ... when they are smaller than the image the kernel doesn't > crash but the image is trashed. Do you have the oops and if you do can you run it threw ksymoops. What color depth are youo running the console at BTW? |
|
From: Geert U. <ge...@li...> - 2001-07-17 07:09:55
|
On Mon, 16 Jul 2001, James Simmons wrote:
> > I checked with Koen Gadeyne who used to work on the XFree86 ET6000 driver, and
> > he has no PDF docs. He sent the paper docs to XFree86 when he stopped working
> > on the driver.
>
> So who has them now?
No idea.
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: Nicu P. <pa...@ra...> - 2001-07-17 06:22:52
|
> > Trying to do some cosmetic :) changes to my machine I generated a > > linux_logo.h to hold an bigger image. > > Change LOGO_W and LOGO_H in fbcon.c. Of course I changed them :) ... when they are just like the image the crash occurs ... when they are smaller than the image the kernel doesn't crash but the image is trashed. -- ......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::...... - iMedia Linux Senior Developer - -- My favorite music : tcpdump > /dev/dsp -- |
|
From: James S. <jsi...@tr...> - 2001-07-16 19:23:28
|
> I checked with Koen Gadeyne who used to work on the XFree86 ET6000 driver, and > he has no PDF docs. He sent the paper docs to XFree86 when he stopped working > on the driver. So who has them now? |
|
From: James S. <jsi...@tr...> - 2001-07-16 19:22:21
|
> Trying to do some cosmetic :) changes to my machine I generated a > linux_logo.h to hold an bigger image. Change LOGO_W and LOGO_H in fbcon.c. |
|
From: Gerd K. <kr...@by...> - 2001-07-16 17:20:34
|
> have we functionality to do rectangle lists, as X does ? Do we need that functionality? > Could this be usefull ? Don't think so, setting alpha bleeding / chroma keying is all we need to have in the kernel. > Clipping is currently done by writting a value to the alpha channel > for each pixel that will show (or not show) the overlay. Then we can > do alpha keyed overlay on them. Cards that don't support alpha keyed > overlay or in mode without alpha channel (depth 8, 16 or 24) you have > to choose a color and use color keyed overlay. You don't need kernel support for this. The fb apps (unlike X11 apps) have direct access to the framebuffer memory. They can simply fill some screen area with the chroma key color. I can't see any need for passing around clip lists. Gerd -- Damn lot people confuse usability and eye-candy. |
|
From: <dol...@cl...> - 2001-07-16 16:17:58
|
> have we functionality to do rectangle lists, as X does ? No, the only hardware accel in 2.2/2.4 is character drawing and rectangle erase (in character unit). > Could this be usefull ? Not for fbcon, maybe for other app. > You need something similar if you want to add clipping support to video > overlay. Well at least for complexe clipping, i guess that for most fb > apps, you would clipp out only a rectangular region, and nothing more > complex. Not if you rely on the app to properly fill the main screen with either an alpha or a color key. it's done only once in a while, so doing it by software shouldn't be too much of a problem. The problem is when fbcon step on your toes by cleaning the alpha channel... > Clipping is currently done by writting a value to the alpha channel for > each pixel that will show (or not show) the overlay. Then we can do alpha > keyed overlay on them. YOu can do the same in FB, only the app mustr handle it. It ain't difficult : the app must mmap() the whole FB area anyway, and the GET_VARINFO IOCTL give the size & offset of the alpha channel. You just have to fill it by software. my pm3fb_setoverlay do that and it works fine, even if the initial filling of the alpha channel is slow. But after that, as long as noone touch your alpha channel, you only need to fill the offscreen buffer. -- DOLBEAU Romain | ENS Cachan / Ker Lann | l'histoire est entierement vraie, puisque Thesard IRISA / CAPS | je l'ai imaginee d'un bout a l'autre dol...@cl... | -- Boris Vian |
754 messages has been excluded from this view by a project administrator.
