Re: [PATCH] Re: [Xen-devel] [RFC] support console resolutions better than 80x25

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

> * 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 
Linux
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
>matter?

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).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel