On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw agnostic DDX driver for instance.
We're fine with 64x64 cursors
On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case
On Tue, 2014-03-25 at 14:59 +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the
On Tue, 2014-03-25 at 14:49 +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw agnostic DDX driver for instance.
We're fine with 64x64 cursors though
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw agnostic DDX driver for instance.
We're fine with 64x64 cursors though and don't need to set those fields
(DRM core will return 64 is
On Tue, Mar 25, 2014 at 03:09:16PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote:
Those fields are supposed to be a
On Tue, Mar 25, 2014 at 04:05:29PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 03:09:16PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote:
On Tue, Mar 25, 2014 at 02:49:30PM
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
For the record,
16:30 agd5f ickle, our GPUs don't have selectable cursor sizes
16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would
allocate a 64x64 cursor and it would look squashed and funky since the
hw
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
Are you saying the Intel DDX currently derives a different meaning to
the intented behaviour? in which case it can still be changed to not do
that?
I still disagree though. This provides all the information I need to
support
On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
For the record,
16:30 agd5f ickle, our GPUs don't have selectable cursor sizes
16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would
allocate a
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
For the record,
16:30 agd5f ickle, our GPUs don't have selectable cursor sizes
16:31 agd5f
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
uint32_t fourcc; /* in */
struct drm_plane_limits
On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
14 matches
Mail list logo
