On Mon, Oct 16, 2000 at 05:22:58PM -0700, James Simmons wrote:
quoted
quoted
quoted
Well, my understanding is that MOL needs to be able to "probe" for all
supported mode. Doing so on a visible console would definitely be hell.
It does that in order to setup the MacOS-side driver mode list.
According to Samuel's last post, MOL needs both var and fix for probing.
Yes this is really bad. The way most drivers are written is that testing
var does not change fix. If you grab fix after testing the video mode it
will be for the current set resolution. Not the one you are testing
for. For most drivers you need to physically set the mode to change
fix. Sometimes the information in fix can only be obtained from the
hardware and this requires a video mode change.
What MOL needs from the fix structure is the bytes_per_line field and
the page_offset of framebuffer. This information is necessary in order
to make it possible to switch seamlessly (by using the MMU) from a
RAM based framebuffer to the physical one.
What I'd like to see is good way to obtain these parameters without
actually setting the video mode. And, of course, it would be nice
if they were guaranteed to be constant for a given video mode.
Cheers,
/Samuel
----------------------------------------------------------
E-mail [off-list ref] WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 17 Oct 2000, Samuel Rydh wrote:
On Mon, Oct 16, 2000 at 05:22:58PM -0700, James Simmons wrote:
quoted
quoted
quoted
quoted
Well, my understanding is that MOL needs to be able to "probe" for all
supported mode. Doing so on a visible console would definitely be hell.
It does that in order to setup the MacOS-side driver mode list.
According to Samuel's last post, MOL needs both var and fix for probing.
Yes this is really bad. The way most drivers are written is that testing
var does not change fix. If you grab fix after testing the video mode it
will be for the current set resolution. Not the one you are testing
for. For most drivers you need to physically set the mode to change
fix. Sometimes the information in fix can only be obtained from the
hardware and this requires a video mode change.
What MOL needs from the fix structure is the bytes_per_line field and
the page_offset of framebuffer. This information is necessary in order
to make it possible to switch seamlessly (by using the MMU) from a
RAM based framebuffer to the physical one.
OK.
What I'd like to see is good way to obtain these parameters without
actually setting the video mode. And, of course, it would be nice
Currently that's possible, but it will no longer be in the future. But I guess
it's only a few modes (640x400, 800x600, 1024x768, 1280x1024), so it won't
cause too much annoyance?
Alternatively you can get the info once and store it in a config file in the
user's homedir. If it later turns out to be invalid (e.g. due to dual-head
issues, or because you changed your video card), you can offer to reprobe when
restarting MOL the next time.
if they were guaranteed to be constant for a given video mode.
That depends on the hardware. When you're running on the second head of e.g. a
Matrox G400, it cannot be guaranteed.
So MOL should test whether those values are still valid when switching from X
to the console, and return to X when they are no longer valid.
Is this acceptable?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
What I'd like to see is good way to obtain these parameters without
actually setting the video mode. And, of course, it would be nice
Currently that's possible, but it will no longer be in the future. But I guess
it's only a few modes (640x400, 800x600, 1024x768, 1280x1024), so it won't
cause too much annoyance?
Only if you open /dev/fb and then do a VT_ACTIVATE. Since /dev/fb is
attached to the tty attached to the process. Well usually. What we could
do is create a ioctl that retrieves fb_fix_screeninfo and fb_var_screeninfo
at the same time. Their also exist the problem of forking with using 2
ioctls to get info the current video mode.
fb_var_screeninfo first_var;
fb_fix_screeninfo fix;
ioctl(fd, FBIOGET_VSCREENINFO, first_var);
ioctl(fd, FBIOGET_FSCREENINFO, fix);
pid = fork();
if (child) {
fb_var_screeninfo different_var_already_made_up;
ioctl(fd, FBIOPUT_VSCREENINFO, different_var_already_made_up;
/* Could be wrong info depending on the card and what platform it is on:-( */
mmap(fix->smem_start, fix->smem_len, ...);
}
The fact is also with many types of hardware setups such as dual head on
matrox as Geert pointed out it might be impossible to do what you want.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/