Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 236510 - graphical install in 480i mode not usable.
Summary: graphical install in 480i mode not usable.
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks: 235611
TreeView+ depends on / blocked
 
Reported: 2007-04-15 16:44 UTC by David Woodhouse
Modified: 2008-05-07 01:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-07 01:29:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Woodhouse 2007-04-15 16:44:53 UTC
With a framebuffer 480 pixels high and using fbdev, such as if you run a PS3
install on a standard television instead of anything better, the installer is
very hard to use because we use a fixed 800x600 window for the installer and all
the useful buttons are off the bottom of the screen.

If X had a virtual screen size of 800x600 but just a smaller viewport, that
would be workable. But if we can't do that we should probably just fall back to
text or VNC.

Comment 1 Jeremy Katz 2007-04-18 15:13:02 UTC
Is there a good way to detect this?  If so, we could fall back to the lowres
(640x480) mode.

It's not as pretty, but it works

Comment 2 David Woodhouse 2007-04-18 15:30:21 UTC
Well, the X server knows the dimensions -- xdpyinfo can tell you, for example.
Is it possible for the graphical installer to query the X server when it starts
up, and go into low-res mode if the screen is smaller than 800x600?

If we need to do it in advance with fbdev, then we could -- we can use the
FBIOGET_VSCREENINFO ioctl on /dev/fb0...

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <linux/fb.h>
#include <sys/ioctl.h>

int main(void)
{
	int ret, fd = open("/dev/fb0", O_RDONLY);
	struct fb_var_screeninfo var;

	if (fd < 0)
		return 1;

	ret = ioctl(fd, FBIOGET_VSCREENINFO, &var);
	if (ret)
		return 1;

	printf("Screen is %d*%d\n", var.xres, var.yres);
}


Comment 3 Jeremy Katz 2007-04-18 23:30:43 UTC
Okay, hopefully put something in place that'll handle this.  Will be in
tomorrow's rawhide

Comment 4 David Woodhouse 2007-04-22 09:10:59 UTC
Doesn't seem to be having the desired effect.

Comment 5 David Woodhouse 2007-04-22 09:30:37 UTC
The change I see in CVS seems to be setting up the X server to do 640x480 mode
-- something it was doing already. Perhaps I'm missing something, but I don't
see how that change is intended to affect the graphical interface of the installer.

That seems to be handled entirely separately in gui.py, but also from code
inspection looks like it should correctly fall back to 640x480 if the width is
less than 800....

        if gtk.gdk.screen_width() >= 800:
            self.runres = "800x600"
        else:
            self.runres = "640x480"


Comment 6 David Woodhouse 2007-04-22 10:51:20 UTC
I've just seen it correctly fall back to 640x480 mode on a different machine,
where X happens to come up at 640x480. I wonder if the fbdev X server isn't
reporting the correct resolution. Will investigate further... I think there
should also be a PS3 in Jesse's cube by now too.

Comment 7 David Woodhouse 2007-04-22 11:29:20 UTC
Ah. It seems the '480i' mode only has 576x384 _visible_ pixels. Perhaps we
should just fall back to text or vnc installation?

We _can_ actually change video mode on the PS3, but I don't think we want the
installer to be involved there; we'll let them set it from the bootloader, and
the kernel can inherit that setting. It depends on what video hardware they have
hooked up, of course. We'll only be using 480i if they have an SD-only NTSC
television, but I think we have to use that as our default mode. 

Now I'm confused though -- the 'full-screen' SD video modes on the PS3 are 480
lines for NTSC and 576 lines for PAL, while the 'normal' modes are 384 and 460
lines respectively. But aren't 480 and 576 _already_ cut down from the full
video signal of 525/625 lines for NTSC/PAL, to match the viewable area? I wonder
why we're losing _more_ of the picture for the PS3?

Comment 8 Red Hat Bugzilla 2007-08-21 05:33:52 UTC
User pnasrat's account has been closed

Comment 9 Bug Zapper 2008-04-04 00:05:47 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 10 Bug Zapper 2008-05-07 01:29:22 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp


Note You need to log in before you can comment on or make changes to this bug.