Menu
▾
▴
linux-fbdev-devel
|
From: Thomas W. <th...@wi...> - 2003-03-11 22:27:06
|
Antonino Daplas wrote: > Unfortunately, this is what we are trying to prevent. X assumes that > the console is in text mode, so only registers that affect text mode are > restored. Frequently, cursor registers and bitmaps, as an example, are > not refreshed. There's probably more, ie accel engine, etc. Argh.. of course, cursor and accelerator registers are usually not restored, you're right at this. But the drivers usually leave the engine in the same state as when started. (A "restore" of accelerator engine registers is mostly impossible, because a complete restore would cause the last command to be executed again) Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Antonino D. <ad...@po...> - 2003-03-11 22:54:56
|
On Wed, 2003-03-12 at 06:27, Thomas Winischhofer wrote: > Antonino Daplas wrote: > > Unfortunately, this is what we are trying to prevent. X assumes that > > the console is in text mode, so only registers that affect text mode are > > restored. Frequently, cursor registers and bitmaps, as an example, are > > not refreshed. There's probably more, ie accel engine, etc. > > Argh.. of course, cursor and accelerator registers are usually not > restored, you're right at this. But the drivers usually leave the engine > in the same state as when started. (A "restore" of accelerator engine > registers is mostly impossible, because a complete restore would cause > the last command to be executed again) > The accel engine is probably not a problem if it uses mmio. However, engines that use command buffers are more susceptible to this if the buffers can be dynamically allocated by the process. The i810 for instance uses ringbuffers. It has to be dynamically allocated via agpgart. Fortunately, the i810 can support 2 ringbuffers, so X can use one and fb the other, so there's no conflict. Then you also have DRI joining in the confusion :-) The best solution, personally, is to have one module controlling chipset access -- DRM for 2D and 3D, and fb for video mode switching. Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-11 23:13:30
|
Antonino Daplas wrote: > The accel engine is probably not a problem if it uses mmio. However, > engines that use command buffers are more susceptible to this if the > buffers can be dynamically allocated by the process. OK, ack. > > The i810 for instance uses ringbuffers. It has to be dynamically > allocated via agpgart. Fortunately, the i810 can support 2 ringbuffers, > so X can use one and fb the other, so there's no conflict. > > Then you also have DRI joining in the confusion :-) Not in my case :) The SiS DRI stuff is made in a way to prevent problems of this kind. But I ack that it might be on others. > The best solution, personally, is to have one module controlling chipset > access -- DRM for 2D and 3D, and fb for video mode switching. Well. I personally don't want every graphics application to depend on kernel modules. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Thomas W. <th...@wi...> - 2003-03-11 22:23:06
|
Antonino Daplas wrote: >>>2. do not refresh unless var changed - fasted but can result in >>>corruption/crash if registers were changed behind the back of fbdev >> >>I think one can rely on tidyness of applications changing the registers. >>Like X does. > > > Unfortunately, this is what we are trying to prevent. X assumes that > the console is in text mode, so only registers that affect text mode are > restored. Frequently, cursor registers and bitmaps, as an example, are > not refreshed. There's probably more, ie accel engine, etc. That surprises me. The X drivers I looked at (quite a bunch) restore all registers (that need to be restored, that is) >>>3. selective refresh - do not refresh if switching between "trusted" >>>consoles, refresh if switching from "untrusted" consoles. >> > > I actually prefer #3, and I already have working code for this. We can > also make this driver switchable (ie, drivers that are not affected by X > can disable this, and only drivers that are affected such as the riva, > aty, radeon, etc can turn this on). What exactly is a "trusted" console? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Antonino D. <ad...@po...> - 2003-03-11 22:54:51
|
On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote: > > > > I actually prefer #3, and I already have working code for this. We can > > also make this driver switchable (ie, drivers that are not affected by X > > can disable this, and only drivers that are affected such as the riva, > > aty, radeon, etc can turn this on). > > What exactly is a "trusted" console? > By default, the pid of each vt is -1. When X loads, it installs its own VT (ie vt7), which in that case the pid of that particular vt == X's pid. We can check this pid, and if switching from a vt with pid == -1, we can safely assume that the hardware state is still sane, and if not, assume the hardware state is undefined. Tony |
|
From: Michel <mi...@da...> - 2003-03-12 00:07:15
|
On Die, 2003-03-11 at 23:51, Antonino Daplas wrote: > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote: > > > > > > I actually prefer #3, and I already have working code for this. We can > > > also make this driver switchable (ie, drivers that are not affected by X > > > can disable this, and only drivers that are affected such as the riva, > > > aty, radeon, etc can turn this on). > > > > What exactly is a "trusted" console? > > By default, the pid of each vt is -1. When X loads, it installs its own > VT (ie vt7), which in that case the pid of that particular vt == X's > pid. We can check this pid, and if switching from a vt with pid == -1, > we can safely assume that the hardware state is still sane, and if not, > assume the hardware state is undefined. Can you also detect when the app has opened the framebuffer device, and assume it's playing nice when it has? (for Option "UseFBDev") -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Antonino D. <ad...@po...> - 2003-03-12 01:05:12
|
On Wed, 2003-03-12 at 08:07, Michel D=E4nzer wrote: > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote: > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote: > > > >=20 > > > > I actually prefer #3, and I already have working code for this. We= can > > > > also make this driver switchable (ie, drivers that are not affected= by X > > > > can disable this, and only drivers that are affected such as the ri= va, > > > > aty, radeon, etc can turn this on). > > >=20 > > > What exactly is a "trusted" console? > >=20 > > By default, the pid of each vt is -1. When X loads, it installs its ow= n > > VT (ie vt7), which in that case the pid of that particular vt =3D=3D X'= s > > pid. We can check this pid, and if switching from a vt with pid =3D=3D= -1, > > we can safely assume that the hardware state is still sane, and if not, > > assume the hardware state is undefined. >=20 > Can you also detect when the app has opened the framebuffer device, and > assume it's playing nice when it has? (for Option "UseFBDev") >=20 X using fbdev will also have the same limitation. I have implemented something like this before. For each fb_open, the current->pid can be saved into a "white list" and removed for each fb_close. fbcon can then compare this to the pid of the vt it's switching from. This is becoming to sound very ugly though. I guess, the best way is to really support Option "UseFBDev", or at least have the user decide if he/she wants to have the hardware refreshed. =20 Tony =20 |
|
From: Michel <mi...@da...> - 2003-03-12 01:29:20
|
On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote: > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote: > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote: > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote: > > > > > > > > > > I actually prefer #3, and I already have working code for this. We can > > > > > also make this driver switchable (ie, drivers that are not affected by X > > > > > can disable this, and only drivers that are affected such as the riva, > > > > > aty, radeon, etc can turn this on). > > > > > > > > What exactly is a "trusted" console? > > > > > > By default, the pid of each vt is -1. When X loads, it installs its own > > > VT (ie vt7), which in that case the pid of that particular vt == X's > > > pid. We can check this pid, and if switching from a vt with pid == -1, > > > we can safely assume that the hardware state is still sane, and if not, > > > assume the hardware state is undefined. > > > > Can you also detect when the app has opened the framebuffer device, and > > assume it's playing nice when it has? (for Option "UseFBDev") > > > > X using fbdev will also have the same limitation. I have implemented > something like this before. For each fb_open, the current->pid can be > saved into a "white list" and removed for each fb_close. fbcon can then > compare this to the pid of the vt it's switching from. I see, makes sense. > This is becoming to sound very ugly though. I guess, the best way is to > really support Option "UseFBDev", or at least have the user decide if > he/she wants to have the hardware refreshed. I'm afraid I don't understand what you're saying here. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Geert U. <ge...@li...> - 2003-03-12 08:27:00
|
On 12 Mar 2003, Michel [ISO-8859-1] D=E4nzer wrote:
> On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 08:07, Michel D=E4nzer wrote:
> > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > >=20
> > > > > > I actually prefer #3, and I already have working code for thi=
s. We can
> > > > > > also make this driver switchable (ie, drivers that are not af=
fected by X
> > > > > > can disable this, and only drivers that are affected such as =
the riva,
> > > > > > aty, radeon, etc can turn this on).
> > > > >=20
> > > > > What exactly is a "trusted" console?
> > > >=20
> > > > By default, the pid of each vt is -1. When X loads, it installs =
its own
> > > > VT (ie vt7), which in that case the pid of that particular vt =3D=
=3D X's
> > > > pid. We can check this pid, and if switching from a vt with pid =
=3D=3D -1,
> > > > we can safely assume that the hardware state is still sane, and i=
f not,
> > > > assume the hardware state is undefined.
> > >=20
> > > Can you also detect when the app has opened the framebuffer device,=
and
> > > assume it's playing nice when it has? (for Option "UseFBDev")
> >=20
> > X using fbdev will also have the same limitation. I have implemented
> > something like this before. For each fb_open, the current->pid can b=
e
> > saved into a "white list" and removed for each fb_close. fbcon can t=
hen
> > compare this to the pid of the vt it's switching from.
The application cannot play not nice unless it mmap()s the MMIO registers=
. To
be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_fla=
gs.
> > This is becoming to sound very ugly though. I guess, the best way is=
to
> > really support Option "UseFBDev", or at least have the user decide if
> > he/she wants to have the hardware refreshed. =20
>=20
> I'm afraid I don't understand what you're saying here.
But I think you do agree :-) He says that if fbdev is active, the X serve=
r has
to be fbdev compliant and thus not mess with the hardware where it's not
allowed to.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
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 <mi...@da...> - 2003-03-12 15:56:28
|
On Mit, 2003-03-12 at 09:24, Geert Uytterhoeven wrote: > On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote: > > On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote: > > > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote: > > > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote: > > > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote: > > > > > > > > > > > > > > I actually prefer #3, and I already have working code for this. We can > > > > > > > also make this driver switchable (ie, drivers that are not affected by X > > > > > > > can disable this, and only drivers that are affected such as the riva, > > > > > > > aty, radeon, etc can turn this on). > > > > > > > > > > > > What exactly is a "trusted" console? > > > > > > > > > > By default, the pid of each vt is -1. When X loads, it installs its own > > > > > VT (ie vt7), which in that case the pid of that particular vt == X's > > > > > pid. We can check this pid, and if switching from a vt with pid == -1, > > > > > we can safely assume that the hardware state is still sane, and if not, > > > > > assume the hardware state is undefined. > > > > > > > > Can you also detect when the app has opened the framebuffer device, and > > > > assume it's playing nice when it has? (for Option "UseFBDev") > > > > > > X using fbdev will also have the same limitation. I have implemented > > > something like this before. For each fb_open, the current->pid can be > > > saved into a "white list" and removed for each fb_close. fbcon can then > > > compare this to the pid of the vt it's switching from. > > The application cannot play not nice unless it mmap()s the MMIO registers. To > be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags. X will map the MMIO registers with Option "UseFBDev" and still play nice (hopefully :). > > > This is becoming to sound very ugly though. I guess, the best way is to > > > really support Option "UseFBDev", or at least have the user decide if > > > he/she wants to have the hardware refreshed. > > > > I'm afraid I don't understand what you're saying here. > > But I think you do agree :-) He says that if fbdev is active, the X server has > to be fbdev compliant and thus not mess with the hardware where it's not > allowed to. I agree that's how it should be. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Thomas W. <th...@wi...> - 2003-03-05 14:19:27
|
Further to my mail from a few minutes ago: I wrote: > But I noticed another issue here: > > When switching to gfx mode during boot (ie as soon as the penguin > appears), the text console is aligned correctly at all edges, with all > lines visible. > But when "initial console" starts, the mode is again changed, and now > the last line of text is nearly invisible, its upper half appears at > the lower screen edge, the lower half is below the screen's edge. The > space between the penguin and the text is notably thicker. > > This can be recovered by switching to another VT and back. This makes > the penguin disappear, and restores the console dimensions/edges to > normal. > Interestingly, this only happens with 800x600; this mode is chosen > upon requesting 800x592 (because of the font size). At 1024x768, > everything is as it should. I am almost sure that this has to do with the fact that I adapt var in my check_var from 800x592 to 800x600. Console (or whoever) seems to attempt to change the mode to its initially desired dimension on many occasions. - This leads to the (unncessary) second mode switch during boot (when the "initial console" starts), assumingly because the xres does not match fontsize * rows, - and probably is the reason for that vertical offset I see after this mode switch: The text area on the screen is shifted down by exactly 8 pixels - 600-592=8 Any hints? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:24:38
|
On Wed, 2003-03-05 at 22:16, Thomas Winischhofer wrote: > > Further to my mail from a few minutes ago: > > I wrote: > > But I noticed another issue here: > > > > When switching to gfx mode during boot (ie as soon as the penguin > > appears), the text console is aligned correctly at all edges, with all > > lines visible. > > > But when "initial console" starts, the mode is again changed, and now > > the last line of text is nearly invisible, its upper half appears at > > the lower screen edge, the lower half is below the screen's edge. The > > space between the penguin and the text is notably thicker. > > > > This can be recovered by switching to another VT and back. This makes > > the penguin disappear, and restores the console dimensions/edges to > > normal. > > > Interestingly, this only happens with 800x600; this mode is chosen > > upon requesting 800x592 (because of the font size). At 1024x768, > > everything is as it should. > > I am almost sure that this has to do with the fact that I adapt var in > my check_var from 800x592 to 800x600. Console (or whoever) seems to > attempt to change the mode to its initially desired dimension on many > occasions. > Strange. If you boot at 800x600, the console will compute that as 100x37. On fbcon_resize, it will request 800x592 but because the difference is only 8, fb_set_var should be skipped, so no mode change should happen throughout. > - This leads to the (unncessary) second mode switch during boot (when > the "initial console" starts), assumingly because the xres does not > match fontsize * rows, At boot time, there are several times the display changes (not necessarily mode changes) -- while the logo is being displayed, after the logo got displayed, and during init. > > - and probably is the reason for that vertical offset I see after this > mode switch: The text area on the screen is shifted down by exactly 8 > pixels - 600-592=8 > > Any hints? > I have no idea. I booted with other drivers at 800x600 and get no ill effects. I get a margin at the bottom of 8 pixels. How about checking what the offsets are during fb_pan_display()? Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-05 16:20:50
|
Antonino Daplas wrote: >> > Strange. If you boot at 800x600, the console will compute that as >> > 100x37. On fbcon_resize, it will request 800x592 but because the >> > difference is only 8, fb_set_var should be skipped, so no mode change >> > should happen throughout. >> >>But it definitely does. I can see this on my LCD (which goes dark during >>mode changes) and, of course, the log. Just check this with the newest versions from fbdev at bk. In my code (which is, as I said in the beginning, the stock 2.5.63 kernel), fbcon_resize does NO check whatsoever. It stupidly calls set_var(). I think that might be one reason for what I see :) Now for a plain dumb question: Is there a patch available to update my kernel tree to the latest fbdev stuff? (I don't intend to spend much time with bk) Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-05 16:43:17
|
On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote: > Antonino Daplas wrote: > >> > Strange. If you boot at 800x600, the console will compute that as > >> > 100x37. On fbcon_resize, it will request 800x592 but because the > >> > difference is only 8, fb_set_var should be skipped, so no mode change > >> > should happen throughout. > >> > >>But it definitely does. I can see this on my LCD (which goes dark during > >>mode changes) and, of course, the log. > > Just check this with the newest versions from fbdev at bk. In my code > (which is, as I said in the beginning, the stock 2.5.63 kernel), > fbcon_resize does NO check whatsoever. It stupidly calls set_var(). Of course. My tree is so modified that I forgot that Jame's latest patch was not yet applied to the main tree :-) > > I think that might be one reason for what I see :) http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note that there is still a bug in fbcon_resize(). 1. in fbcon_resize(), p->vrows must be updated unconditionally 2. fbcon_resize() in fbcon_switch() must be moved higher up the code, preferably before the scroll_phys_max calculation. Tony |
|
From: Geert U. <ge...@li...> - 2003-03-05 17:03:46
|
On 6 Mar 2003, Antonino Daplas wrote: > On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote: > > Antonino Daplas wrote: > > >> > Strange. If you boot at 800x600, the console will compute that as > > >> > 100x37. On fbcon_resize, it will request 800x592 but because the > > >> > difference is only 8, fb_set_var should be skipped, so no mode change > > >> > should happen throughout. > > >> > > >>But it definitely does. I can see this on my LCD (which goes dark during > > >>mode changes) and, of course, the log. > > > > Just check this with the newest versions from fbdev at bk. In my code > > (which is, as I said in the beginning, the stock 2.5.63 kernel), > > fbcon_resize does NO check whatsoever. It stupidly calls set_var(). > > Of course. My tree is so modified that I forgot that Jame's latest > patch was not yet applied to the main tree :-) > > > > I think that might be one reason for what I see :) > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note that this patch is dated Feb 20. In the mean time James applied at least your accel_putcs() optimizations and my logo updates. 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: James S. <jsi...@in...> - 2003-03-05 19:27:04
|
> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > Note that this patch is dated Feb 20. In the mean time James applied at least > your accel_putcs() optimizations and my logo updates. Please note I just release a new patch. Please try it out. |
|
From: James S. <jsi...@in...> - 2003-03-05 19:28:37
|
> > I think that might be one reason for what I see :) > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz > > Note that there is still a bug in fbcon_resize(). > > 1. in fbcon_resize(), p->vrows must be updated unconditionally Applied in latest patch. > 2. fbcon_resize() in fbcon_switch() must be moved higher up the code, > preferably before the scroll_phys_max calculation. Do you have a patch? |
|
From: James S. <jsi...@in...> - 2003-03-05 18:58:54
|
> I am currently porting the SiS framebuffer driver to the - more or less > - new API. Better late than never :) > > Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for > development, no fbdev patches) Please try your driver with the patch I post and tell me what problems you still have. Most of those shoudl have been fixes now. |
Thanks for helping keep SourceForge clean.
X