This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [PATCH] Re: [Xen-devel] [RFC] support console resolutions better tha

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [PATCH] Re: [Xen-devel] [RFC] support console resolutions better than 80x25
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 15 Aug 2006 18:11:49 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 15 Aug 2006 09:12:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1079FEC.E78%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44E18A8B.76E4.0078.0@xxxxxxxxxx> <C1079FEC.E78%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> * What do the values of the video_type and txt_mode fields mean? Do we need
>to provide enumerations, or refer to VESA type codes?

video_type is the equivalent of Linux' orig_video_isVGA (which is namely used
to distinguish between VGA text and VESA lfb based screen setups), whereas
txt_mode is the equivalent of Linux' orig_video_mode, representing the specific
(BIOS INT 10) mode that was in effect when booting.
While clearly these could be combined into a single field, keeping things the 
way seemed simpler to me.

> * txt_points might be better named txt_font_height?

Yes, if you like this better. The naming was just following Linux'.

> * txt_x/txt_y aren't written by Xen nor are they read by Linux -- can we
>kill the fields?

Linux actually uses orig_y (in earlyprintk.c), so I'd like to keep them and
at some point properly fill them so Linux can propagate these values.
You'll note that currently I simply set orig_y to the end of the screen, since
Xen is virtually guaranteed to push out at least a screenful of information
before starting Linux.
The problem here is that these fields cannot be set in fill_console_info, but
would need to be set once it is certain that there is not going to be any
more (non-debug) output from Xen.

> * video_width/height is used to initialise *both* text cols/rows and lfb
>width/height in Linux. Is this okay (since only one or the other is valid)
>or should we provide two sets of fields in console_info (perhaps txt_x/y
>were intended for this purpose)?

I intentionally combined the two (redundant) Linux fields into one;
video_type disambiguates them.

> * rsvd_pos/size is obviously cribbed from the Linux structure. Perhaps they
>should be renamed as transp_pos/size or, since I think they're not used on
>x86 at least, just be removed for now?

>From Linux, and they in turn inherited it from VESA. Renaming it seems okay
(as transparency is the only known possible meaning for them), but I'd like
to keep the fields.

>Also, what about the screen_info fields that don't have a console_info
>equivalent -- e.g., orig_video_page, pages, vesa_attributes -- do these not

For these I didn't see their usefulness; pages and vesa_attributes (and then
also capabilities) could potentially be of use (though in a pure lfb setup
pages at least shouldn't matter).


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>