The output is not centered.
I am not sure how to achieve that because SDL just sets a "video mode"
which starts at upper left corner of the window.
It would be possible to make the mode larger but then the zoom routines
would have to take an offset.
Signed-off-by: Michal Suchanek
enabled.
Thanks
Michal
Signed-off-by: Michal Suchanek
---
hw/isa.h|1 +
hw/pckbd.c | 36 +---
qemu-options.hx |9 +
vl.c|4
4 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/hw/isa.h b/hw/isa.h
On 11 March 2010 16:17, James Simmons wrote:
>
>> >> It would be nice to find a way to reclaim the console memory for X,
>> >> but I'm not sure that can be done and still provide a good way to
>> >> provide oops support.
>> >
>> > What do you think the average user will care about more?
>> >
>> >
On 10 March 2010 19:47, James Simmons wrote:
>
>> >> Yuck. See my other post about what fbdev really means in its historical
>> >> context. The struct fb_info really maps better to drm_crtc than to
>> >> drm_framebuffer. In fact take the case of the matrox fbdev driver. It
>> >> creates two frameb
On 10 March 2010 18:42, James Simmons wrote:
>
>> >> At the moment the problem with fbset is what to do with it in the
>> >> dual head case. Currently we create an fb console that is lowest
>> >> common size of the two heads and set native modes on both,
>> >
>> > Does that mean that fbset is supp
On 10 March 2010 22:04, Ville Syrjälä wrote:
> On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote:
>>
>> > I don't think so. There is another driver which does this -
>> > vesa/uvesa. For these it is not possible to change the resolution from
>> > fbdev, it just provides some framebuffe
On 3 March 2010 10:23, Dave Airlie wrote:
>>>
>>>
>>> I've only really got two answer for this:
>>>
>>> (a) hook up another /dev/dri/card_fb device and use the current KMS
>>> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
>>> to mention resizes etc. Or add one or two in
On 3 March 2010 06:02, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek wrote:
>> On 21 November 2009 05:27, Dave Airlie wrote:
>>
>>> At the moment the problem with fbset is what to do with it in the
>>> dual head case. Currently we cr
On 21 November 2009 05:27, Dave Airlie wrote:
> At the moment the problem with fbset is what to do with it in the
> dual head case. Currently we create an fb console that is lowest
> common size of the two heads and set native modes on both,
Does that mean that fbset is supposed to work (set res
Hello
2009/6/2 Andrew Morton :
> On Sat, 30 May 2009 13:58:33 +0200
> Krzysztof Helt wrote:
>
>> The intelfb driver sets color map depending on currently active pipe.
>> However, if an LVDS
>> display is attached (like in laptop) the active pipe variable is never set.
>> The default value is
>>
2009/6/4 Krzysztof Helt :
> On Wed, 3 Jun 2009 11:27:17 +0200
> Michal Suchanek wrote:
>
>> Unfortunately I did not get to testing the patch yet.
>>
>> According to the description it is supposed to resolve some confusion
>> over what pipe is enabled or not.
2009/6/2 Andrew Morton :
> On Sat, 30 May 2009 13:58:33 +0200
> Krzysztof Helt wrote:
>
>> The intelfb driver sets color map depending on currently active pipe.
>> However, if an LVDS
>> display is attached (like in laptop) the active pipe variable is never set.
>> The default value is
>> PIPE_A
2009/5/17 Krzysztof Helt :
> On Sat, 16 May 2009 23:19:32 -0700
> Andrew Morton wrote:
>
>> On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt
>> wrote:
>>
>> > This is not a regression. I have reproduced it in the 2.6.28 easily.
>>
>> hm, Dean's original report had
>>
>> This does not occur
13 matches
Mail list logo
