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: <dol...@cl...> - 2001-06-26 21:18:12
|
> This happens every time you VC switch. [snip] > But because of the way the current console system > is designed the colormap will always be set on VC switches. The fix wasn't intended for VC switch, but for any change of fb_var_screeninfo parameter. Those can happen without VC switching, that's exactly what 'fbset' is for. If on your console you do a 'fbset -depth 16 -rgba 5,6,5,0' followed by a 'fbset -depth 16 -rgba 5,5,5,1' [1], any driver using fbdev will end up with a crazy colormap because it hasn't been reinstalled after the RGBA change. Hence the need for the fix. [1] yes, in fbset, "-depth" really mean "-bpp" ... -- 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 |
|
From: James S. <jsi...@tr...> - 2001-06-26 20:27:06
|
> For the color component, yes, but you can't use a memcmp > on the 'fb_var_screeninfo', as some member of the struct > are irrelevant to colormap switching (you don't want > to reinstall the colormap if only the refresh rate changed, > for instance). But it does. If you look at the console code it always calls set_palette which in turn calls fbcon_set_palette which in turn calls fb_set_cmap. This happens every time you VC switch. A few driver writers noticed this and don't bother with calling fb_Set_var in con_switch but instead a few pieces of the function. But because of the way the current console system is designed the colormap will always be set on VC switches. |
|
From: James S. <jsi...@tr...> - 2001-06-26 19:36:47
|
Ha!!!!! That problem again. We really need to add currcon to fb_info until 2.5.X rolls around. On Tue, 26 Jun 2001, David T Eger wrote: > For those drivers based on skeletenfb.c (thank you Geert) there is a static > variable currcon. I am trying to implement support for multiple cards. > How does this variable relate, how should I futz with it, should I keep a > copy for each video card, what? I see that it is used in the standard cmap > allocation... |
|
From: David T E. <dt...@us...> - 2001-06-26 19:26:17
|
For those drivers based on skeletenfb.c (thank you Geert) there is a static variable currcon. I am trying to implement support for multiple cards. How does this variable relate, how should I futz with it, should I keep a copy for each video card, what? I see that it is used in the standard cmap allocation... -David |
|
From: Geert U. <ge...@li...> - 2001-06-26 19:22:26
|
On Tue, 26 Jun 2001, Otto Wyss wrote:
> > I've inserted a printk-statement (with "KERN_INFO") right at the
> > beginning of fb_find_mode (kernel 2.4.5, i386) but it isn't shown during
>
> Now I know it, in include/linux/fb.h fb_find_mode was redefined with
> #define MODULE. Why this and why here? Shouldn't this redefinition be in
> modedb.c if any?
Modedb is available for builtin drivers only.
To avoid people having to change anything in their driver to find the initial
video mode, fb_find_mode() is redefined to provide standard VGA 640x80 only in
the modular case.
As soon as __init works in modules, we can consider adding modedb to modular
drivers.
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: Otto W. <ott...@bl...> - 2001-06-26 18:51:04
|
> I've inserted a printk-statement (with "KERN_INFO") right at the > beginning of fb_find_mode (kernel 2.4.5, i386) but it isn't shown during Now I know it, in include/linux/fb.h fb_find_mode was redefined with #define MODULE. Why this and why here? Shouldn't this redefinition be in modedb.c if any? O. Wyss |
|
From: James S. <jsi...@tr...> - 2001-06-26 18:39:12
|
> I just upgraded to Ralph's Mips 2.4.5 tree. > > My console on fb appears to be working... Do a cat /dev/urandom > /dev/fb0. If this works then the driver works and somehow the mips tree broke mmap. > I assume this is the result of the API change? The api changes went in months ago. The wrapper doesn't touch the fbdev internals. It just acts as a brigde between both apis. BTW it hasn't gone in to my knowledge. > >http://www.sf.net/projects/linux-mips So I see you are playing with the secondary mips tree :-) |
|
From: Scott A M. <sam...@co...> - 2001-06-26 18:09:18
|
James Simmons wrote: > I have a patch that provides a wrapper for the new api avaliable for > download. http://www.transvirtual.com/~jsimmons/newapi.diff.gz. It is > quite big. Pretty much it has a second generation of fbgen. Actually I was > thinking was if we could actually change fbgen gradually over ot the new > api this would be a better approach. I need to work with the people how > wrote fbdev using fbgen. So please step forward. > I just upgraded to Ralph's Mips 2.4.5 tree. My console on fb appears to be working... I have a simple program that maps a frame buffer into user space and draws an image onto the fb. This program worked fine under 2.4.3 however under 2.4.5 the program runs but nothing appears on the FB. The memory I am writing to does not appear to be the frame buffer. I assume this is the result of the API change? X cause the kernel to lock with no messages I assume because of the same API change. Will the above link be of use to me or should I start with: >We have started a secondary tree for linux mips. This tree will >be to SGI mips tree as Alan Cox's tree is to linus branch. We will test >and play with "experimental patches" and then in time hand them off to the >main branch Ralf Baechle maintains. Also one of the main reasons for this >branch was to unite several of the mips trees into one place. Anyones >patches (if good) are welcomed. The site is > >http://www.sf.net/projects/linux-mips Thanks for any guidance -- Scott A. McConnell |
|
From: Romain D. <do...@ir...> - 2001-06-26 08:32:21
|
Romain Dolbeau wrote: > the attached patch fix a problem with fbgen when changing the > RGBA components but not the depth ; fbgen would not change > the colormap in this case, where it should. This is the same patch but using memcmp() on the 3 color components. -- 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: Michel <mic...@ii...> - 2001-06-25 19:51:42
|
Ghozlane Toumi wrote: > > ----- Original Message ---- > From: "Michel Dänzer" <mic...@ii...> > Subject: Re: [Linux-fbdev-devel] XFbdev and frame buffer driver > > > Ghozlane Toumi wrote: > > > If from X i switch back to a console driven by the driver, X dies > > > horibly with a seg 11 . > > > > I suggest looking at the ioctls it uses > (xc/programs/Xserver/hw/kdrive/fbdev/) > > and make sure your driver fully supports them. > > ok, thank you... > i huess this may be a good explanation as i did'nt know X_FBdev was using > specificts ioctls ;-) I'm not sure anymore though - are you talking about the 3.3.x XF68_FBDev (or XF86_FBDev) or the new 4.x Xfbdev? The source for the former is somewhere in xc/programs/Xserver/hw/xfree68/ . Both boil down to the same ioctls though I assume. -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Mayuresh D. <ma...@ya...> - 2001-06-25 18:36:13
|
I have two questions:
1) i have a photocell connected on my screen which
tells me my refresh rate.
how can i send a signal from the parallel port maybe
that syncs with the vertical refresh signal. How do i
know that it is exactly syncing.
2) Suppose a have a switch. How do i flip frames (or
screens) using the fb device or in any other
appropiate way when i turn the switch on/off??
Thanks,
Mayuresh
**********************************************
Mayuresh Deorukhkar
Graduate Research Assistant
University Of Missouri - Columbia
**********************************************
On Wed, 6 Jun 2001, Deorukhkar, Mayuresh S.
(UMC-Student) wrote:
> Hi,
>
> we are working on real time linux and we want to
know when a screen
refresh
> occurs.
> How do we detect a vertical refresh strobe??
>
The right way to do it is via interrupt, however X is
completely in
userspace so you need to write a kernel driver to
catch this interrupt.
At least as far as ATI cards are concerned it is
fairly easy to intruct
them to make this interrupt. Just be careful of dri
interactions - the
very same interrupt is used for everything else too.
Vladimir Dergachev
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
|
|
From: Mayuresh D. <ma...@ya...> - 2001-06-25 18:35:35
|
I have two questions:
1) i have a photocell connected on my screen which
tells me my refresh rate.
how can i send a signal from the parallel port maybe
that syncs with the vertical refresh signal. How do i
know that it is exactly syncing.
2) Suppose a have a switch. How do i flip frames (or
screens) using the fb device or in any other
appropiate way when i turn the switch on/off??
Thanks,
Mayuresh
**********************************************
Mayuresh Deorukhkar
Graduate Research Assistant
University Of Missouri - Columbia
**********************************************
On Wed, 6 Jun 2001, Deorukhkar, Mayuresh S.
(UMC-Student) wrote:
> Hi,
>
> we are working on real time linux and we want to
know when a screen
refresh
> occurs.
> How do we detect a vertical refresh strobe??
>
The right way to do it is via interrupt, however X is
completely in
userspace so you need to write a kernel driver to
catch this interrupt.
At least as far as ATI cards are concerned it is
fairly easy to intruct
them to make this interrupt. Just be careful of dri
interactions - the
very same interrupt is used for everything else too.
Vladimir Dergachev
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
|
|
From: Marcel W. <ma...@wf...> - 2001-06-25 13:13:03
|
Geert Uytterhoeven wrote: >However, there are other Vaio models with other LCD panel resolutions. I'll >give it a try on mine (PCG-Z600TEK with 1024x768 panel). > It should not be to difficult to make that work, as you can see the patch does litle more than removing the shadow at the end of the display and making the cursor start a the (real) beginning of a line. Please let me know if it works. >Perhaps we can get the model name from the BIOS and map it to the panel >resolution using a table? > That would be nice, however I do not have any clue on how to make that work. > Alternatively we need a `panel:<xres>x<yres>' option. > I'm not sure if this would work. I did some tweaking using fbset and modeline utility to make the modedb.c entry for the Vaio C1VE lcd. I don't thing it is easy to automate this procedure. thanks, * Marcel Wijlaars * <cid:par...@ne...> Eindhoven University of Technology Mechanical Engineering Materials Technology PO Box 513 ,WH 4.111 5600 MB Eindhoven, The Netherlands Tel: +31 40 247 4813 Fax: +31 40 244 7355 Email: ma...@wf... <mailto:ma...@wf...> |
|
From: Romain D. <do...@ir...> - 2001-06-25 08:14:15
|
James Simmons wrote: > > > the attached patch fix a problem with fbgen when changing the > > RGBA components but not the depth ; fbgen would not change > > the colormap in this case, where it should. > > It would be much easier to use a memcmp. For the color component, yes, but you can't use a memcmp on the 'fb_var_screeninfo', as some member of the struct are irrelevant to colormap switching (you don't want to reinstall the colormap if only the refresh rate changed, for instance). -- 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-06-25 07:34:51
|
On Mon, 25 Jun 2001, Marcel Wijlaars wrote:
> I made some small changes to the atyfb device driver to enable full
> width framebuffer console (1024x480) for the Sony Vaio C1VE. Some people
> asked me to submit my patch (see attachments) to the standard kernel
> (Alan Cox's tree).
> Do you think this patch would be accepted?
This one looks fine.
However, there are other Vaio models with other LCD panel resolutions. I'll
give it a try on mine (PCG-Z600TEK with 1024x768 panel).
Perhaps we can get the model name from the BIOS and map it to the panel
resolution using a table? Alternatively we need a `panel:<xres>x<yres>' option.
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 <da...@io...> - 2001-06-25 07:04:21
|
Benjamin Herrenschmidt wrote: > > >This time it's against Linus' (or rather Debian's, but I doubt there are > >any Debian specific aty128fb changes) 2.4.5 . > > > > > >Question: the palette of the second head is still programmed for the M3, > >but BenH has that #if 0'ed out in his tree - any consensus yet as to if > >it's actually necessary? > > It's only necessary if the second DAC is actually used, which is never > the case, currently, with aty128fb. It's the case however with offb when > OF itself sets the card in dual head mode. But that's none of aty128fb's business is it? :) What about non-PPC platforms? Thanks, -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Ghozlane T. <gt...@pr...> - 2001-06-25 03:19:58
|
Hi all... Can some one explain to me the way the actual (2.4/2.2) code changes the video mode when one switch VC's ? my problem is that the do_change_videomode() functions seems to be called in most fb_drivers from 2 places : xxxfb_set_var() and xxxfb_switch_con functions, the "problem" being that xxxfb_set_var() calls fb_info.changevar() witch in turn calls do_change_videomode()... If I'm not too tired, that makes 2 calls to do_change videomode when someone calls set_var ? If I want to avoid flickering when changinf VCs, where should I test for resolution changes: before programming the videomode ? in set_var ? switch_con ? both ? actualy i think i'l a little bit confused with the supposed jobs of xxxfb_set_var and xxfb_switch_con .. the first is called whan someone changes the resolution via fbset, the last one when someone switches VCs ? thank you for the help, I just hope I didn't make a fool of myself by misreading the code ... ghoz PS actualy, i think just writing this email is helping me clearing the fog ... |
|
From: Ghozlane T. <gt...@pr...> - 2001-06-25 03:02:05
|
----- Original Message ---- From: "Michel D=E4nzer" <mic...@ii...> Subject: Re: [Linux-fbdev-devel] XFbdev and frame buffer driver > Ghozlane Toumi wrote: > > If from X i switch back to a console driven by the driver, X dies horibly > > with a seg 11 . > > I suggest looking at the ioctls it uses (xc/programs/Xserver/hw/kdrive/fbdev/) > and make sure your driver fully supports them. ok, thank you... i huess this may be a good explanation as i did'nt know X_FBdev was using specificts ioctls ;-) ghoz |
|
From: Benjamin H. <be...@ke...> - 2001-06-24 22:12:47
|
>This time it's against Linus' (or rather Debian's, but I doubt there are any >Debian specific aty128fb changes) 2.4.5 . > > >Question: the palette of the second head is still programmed for the M3, but >BenH has that #if 0'ed out in his tree - any consensus yet as to if it's >actually necessary? It's only necessary if the second DAC is actually used, which is never the case, currently, with aty128fb. It's the case however with offb when OF itself sets the card in dual head mode. Ben. |
|
From: Sven L. <lu...@dp...> - 2001-06-24 21:18:55
|
On Sun, Jun 24, 2001 at 01:27:38PM -0700, James Simmons wrote: > > > > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > > > "text" mode. When swithcing from one to the other it will place the engine > > > in a different state. > > > > Fine, but what's the _reason_ not to use the DRM? :) > > DRM is overkill for what we need. It would only end up bloating the > system. We just need to setup the DMA engine and send in 3 basic 2D > accels. mmm, ... I am thinking of a user-space library to do video acceleration on the framebuffer, for initial use with vlc, as it already has an fbdev output option. If i want to do dma with this library, should i need to use the drm, or is some other possibilities available ? How will a user-space library using the accel engine (it would clearly need a little 'driver' for each chip) cohabit with the acceleration used with fbcon ? Also i suppose by "graphic" mode you are speaking about X, and by "text" mode, you are speaking about fbcon ? Who will be responsible for setting the accel engine in a different state ? as XFree clearly thinks it is his responsability to do such. Or are you thinking only about the new X server ? Friendly, Sven Luther |
|
From: Michel <mic...@ii...> - 2001-06-24 20:35:54
|
http://n.ethz.ch/student/daenzerm/download/fbdev/aty128fb-16bit.diff This time it's against Linus' (or rather Debian's, but I doubt there are any Debian specific aty128fb changes) 2.4.5 . Question: the palette of the second head is still programmed for the M3, but BenH has that #if 0'ed out in his tree - any consensus yet as to if it's actually necessary? -- 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-06-24 20:27:44
|
> > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > > "text" mode. When swithcing from one to the other it will place the engine > > in a different state. > > Fine, but what's the _reason_ not to use the DRM? :) DRM is overkill for what we need. It would only end up bloating the system. We just need to setup the DMA engine and send in 3 basic 2D accels. > In the XFree86 r128 driver, it looks rather easy... Besides, by 'switching' I > meant replacing the MMIO accel functions by DMA ones. Okay. That is fine. |
|
From: Michel <mic...@ii...> - 2001-06-24 20:18:11
|
James Simmons wrote: > > > I hope this is going to use the existing DRM infrastructure? > > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > "text" mode. When swithcing from one to the other it will place the engine > in a different state. Fine, but what's the _reason_ not to use the DRM? :) > > Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it > > can't hurt to have the basic support in place when doing it, can it? > > Well the driver will be completely different. CCE is very different from > MMIO mode for the Rage 128. I found switching between the two to be very > tricky. In the XFree86 r128 driver, it looks rather easy... Besides, by 'switching' I meant replacing the MMIO accel functions by DMA ones. -- 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-06-24 20:14:30
|
> I hope this is going to use the existing DRM infrastructure? No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to "text" mode. When swithcing from one to the other it will place the engine in a different state. > Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it can't > hurt to have the basic support in place when doing it, can it? Well the driver will be completely different. CCE is very different from MMIO mode for the Rage 128. I found switching between the two to be very tricky. |
|
From: Michel <mic...@ii...> - 2001-06-24 18:06:14
|
James Simmons wrote: > > > > BTW I'd love to work on adding Rage128 and Radeon support to the new > > > atyfb. > > > > Please coordinate with Ani, he already started to work on that. > > Is this such a wise idea? I know the ati 128 can be run in DMA mode but > can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the > patches I have go in we can migrate to using DMA/irq. I hope this is going to use the existing DRM infrastructure? Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it can't hurt to have the basic support in place when doing it, can it? -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
754 messages has been excluded from this view by a project administrator.
