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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 15/8/06 7:49 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> It'd be nice if we could also have the Linux-style linearfb code, so
> we
>> could use the higher res graphics modes. I suppose that would be a lot
> more
>> work though, and should fit in the framework that this patch provides
> (in
>> particular, the info structure passed to domain0 should be able to
> support
>> that, right)?
> 
> Yes, that was the plan for the next step.

Looking at the console_info structure some more, I wonder if it could do
with some cleaning up. Currently it seems to be a halfway house between
being a duplicate of the Linux screen_info structure and an independent
structure in its own right. Hence the meaning of some of the fields is
unclear.

Here are some comments we should address before we fork 3.0.3 this week:
 * 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?
 * txt_points might be better named txt_font_height?
 * txt_x/txt_y aren't written by Xen nor are they read by Linux -- can we
kill the fields?
 * 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)?
 * 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?

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?

 -- Keir




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