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 s
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 t
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 machine, enable KVM
- boot the mac
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 s
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 machine, enable KVM
- boot the mac
