[Spice-devel] [drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Dave Airlie]

On 4 November 2016 at 20:41, Christophe Fergeau  wrote:
> On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
>> > Or maybe other parts of the
>> > kernel/userspace rely on this rounding down.
>>
>> This is where I suspect we could run in trouble.  Odd resolutions simply
>> don't happen on physical hardware, all usual resolutions are a multiple
>> of 8, most of them are even a multiple of 16.
>>
>> Various image/video formats use 16x16 blocks.
>> The qemu vnc server operates on 16x16 blocks too (and we had bugs in the
>> past with odd resolutions).
>>
>> Also scanlines and cachelines align nicely if you don't use odd
>> resolutions.
>>
>> > I unfortunately don't know
>> > :(
>>
>> I don't have definitive answers too, just a gut feeling that this might
>> cause trouble.
>
> I think this might be fine actually, there is already one such
> resolution in the kernel, which is 1366x768 (1366 is only a multiple of
> 2). There is already a bit of a hack to handle it anyway, see
> fixup_mode_1366x768() in drm_edid.c.
>
>>
>> Maybe we should add a module option for this?  So there is an easy
>> (as-in: doesn't require a kernel rebuild) way out in case it causes
>> trouble in certain setups?
>
> This seems a bit overkill to me, but I can look into it if needed.

I think we should try it an see, if we see problems you could enforce
the framebuffer
would have a stride aligned to whatever value, and just the view into
the framebuffer
could be whatever.

The CVT stuff is just due to how hw is programmed and monitors are described.

Dave.

[Spice-devel] [drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Gerd Hoffmann]

  Hi,

> I think we should try it an see,

Ok, lets try.  I'll go pick them up and prepare a pull with this and
some virtio-gpu bits,

  Gerd

[Spice-devel] [drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Christophe Fergeau]

On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
> > Or maybe other parts of the
> > kernel/userspace rely on this rounding down.
> 
> This is where I suspect we could run in trouble.  Odd resolutions simply
> don't happen on physical hardware, all usual resolutions are a multiple
> of 8, most of them are even a multiple of 16.
> 
> Various image/video formats use 16x16 blocks.
> The qemu vnc server operates on 16x16 blocks too (and we had bugs in the
> past with odd resolutions).
> 
> Also scanlines and cachelines align nicely if you don't use odd
> resolutions.
> 
> > I unfortunately don't know
> > :(
> 
> I don't have definitive answers too, just a gut feeling that this might
> cause trouble.

I think this might be fine actually, there is already one such
resolution in the kernel, which is 1366x768 (1366 is only a multiple of
2). There is already a bit of a hack to handle it anyway, see
fixup_mode_1366x768() in drm_edid.c.

> 
> Maybe we should add a module option for this?  So there is an easy
> (as-in: doesn't require a kernel rebuild) way out in case it causes
> trouble in certain setups?

This seems a bit overkill to me, but I can look into it if needed.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: