On Tue, Mar 20, 2012 at 05:48:14PM +0100, Marcus Lorentzon wrote:
> Then it would also be nice to define some rules in KMS of what should be
> modeset params and what should be properties. Modeset params seems hard
> to add (struct change) and properties seems very loosely defined and
> device
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers
From: Paulo Zanoni
This property is needed so we can inform the KVMr feature about our
current rotation: whenever we change the rotation, we should change
that property so that the KVMr knows that the screen is rotated.
How to reproduce the problem:
- on an AMT
From: Paulo Zanoni paulo.r.zan...@intel.com
This property is needed so we can inform the KVMr feature about our
current rotation: whenever we change the rotation, we should change
that property so that the KVMr knows that the screen is rotated.
How to reproduce the problem:
- on an AMT machine,
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers
On Tue, Mar 20, 2012 at 05:48:14PM +0100, Marcus Lorentzon wrote:
Then it would also be nice to define some rules in KMS of what should be
modeset params and what should be properties. Modeset params seems hard
to add (struct change) and properties seems very loosely defined and
device