* KMS cursor BO semantics @ 2011-11-04 11:59 Thomas Hellstrom 2011-11-04 14:36 ` Ilija Hadzic 2011-11-04 15:34 ` Daniel Vetter 0 siblings, 2 replies; 13+ messages in thread From: Thomas Hellstrom @ 2011-11-04 11:59 UTC (permalink / raw) To: dri-devel@lists.freedesktop.org Hi. I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: Some hardware (vmware's virtual in particular) may not be able to pick up the changes from a bo directly, since the cursor data is sent though the command stream. Hence we need a notification when the cursor image has changed. Could we *require* that a cursor image change needs to be followed by an ioctl call with the flag DRM_MODE_CURSOR_BO? Thanks, Thomas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 11:59 KMS cursor BO semantics Thomas Hellstrom @ 2011-11-04 14:36 ` Ilija Hadzic 2011-11-04 14:38 ` Thomas Hellstrom 2011-11-04 15:34 ` Daniel Vetter 1 sibling, 1 reply; 13+ messages in thread From: Ilija Hadzic @ 2011-11-04 14:36 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org On Fri, 4 Nov 2011, Thomas Hellstrom wrote: > Hi. > > I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: > > Some hardware (vmware's virtual in particular) may not be able to pick up the > changes from a bo directly, since the cursor data is sent though the command > stream. Hence we need a notification when the cursor image has changed. > > Could we *require* that a cursor image change needs to be followed by an > ioctl call with the flag > DRM_MODE_CURSOR_BO? > > Thanks, > Thomas > FWIW, Acked-by: Ilija Hadzic <ihadzic@research.bell-labs.com> I have a few places where I could use such an ioctl. BTW, Thomas, in the above "since the cursor data is sent though the command stream", did you mean "since the cursor data is *not* sent though the command stream". If it was sent, through command stream, then CS ioctl would know when the cursor changes. My understanding is that the cursor data are mmap-ed letting userland poke it at will (so the case when an "hourglass" changes into "arrow" is particularly hard to know that it happened). -- Ilija ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 14:36 ` Ilija Hadzic @ 2011-11-04 14:38 ` Thomas Hellstrom 0 siblings, 0 replies; 13+ messages in thread From: Thomas Hellstrom @ 2011-11-04 14:38 UTC (permalink / raw) To: Ilija Hadzic; +Cc: dri-devel@lists.freedesktop.org On 11/04/2011 03:36 PM, Ilija Hadzic wrote: > > > On Fri, 4 Nov 2011, Thomas Hellstrom wrote: > >> Hi. >> >> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR >> iotcl: >> >> Some hardware (vmware's virtual in particular) may not be able to >> pick up the changes from a bo directly, since the cursor data is sent >> though the command stream. Hence we need a notification when the >> cursor image has changed. >> >> Could we *require* that a cursor image change needs to be followed by >> an ioctl call with the flag >> DRM_MODE_CURSOR_BO? >> >> Thanks, >> Thomas >> > > FWIW, Acked-by: Ilija Hadzic <ihadzic@research.bell-labs.com> > I have a few places where I could use such an ioctl. > Well, the idea was to reuse the DRM_IOCTL_MODE_CURSOR ictl that sets the cursor BO, and require that it is re-emitted once the cursor image has changed, since I guess that's what many X servers do anyway. > BTW, Thomas, in the above "since the cursor data is sent though the > command stream", did you mean "since the cursor data is *not* sent > though the command stream". If it was sent, through command stream, > then CS ioctl would know when the cursor changes. I meant the device interface, not the drm interface. So when we have a new cursor image, we need to collect the scanline data an send it through the device command stream. We don't export that possibility in the DRM interface. > > My understanding is that the cursor data are mmap-ed letting userland > poke it at will (so the case when an "hourglass" changes into "arrow" > is particularly hard to know that it happened). Yes. Hardware that scan out directly from the cursor BO don't really need to know, but we do. > > -- Ilija Thanks, /Thomas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 11:59 KMS cursor BO semantics Thomas Hellstrom 2011-11-04 14:36 ` Ilija Hadzic @ 2011-11-04 15:34 ` Daniel Vetter 2011-11-04 22:30 ` Thomas Hellstrom 1 sibling, 1 reply; 13+ messages in thread From: Daniel Vetter @ 2011-11-04 15:34 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: > Hi. > > I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: > > Some hardware (vmware's virtual in particular) may not be able to > pick up the changes from a bo directly, since the cursor data is > sent though the command stream. Hence we need a notification when > the cursor image has changed. > > Could we *require* that a cursor image change needs to be followed > by an ioctl call with the flag > DRM_MODE_CURSOR_BO? On i915 we need the cursor in physical memory for some (old) platforms, which is seperate storage from the bo backing storage. So we have the same problem. We've solved it by intercepting pwrite ioctl calls and demanding that userspace only uses these for cursor updates. Is there a special reason you can't use such a driver-specific trick? -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 15:34 ` Daniel Vetter @ 2011-11-04 22:30 ` Thomas Hellstrom 2011-11-04 22:49 ` Maarten Maathuis 2011-11-05 16:10 ` Daniel Vetter 0 siblings, 2 replies; 13+ messages in thread From: Thomas Hellstrom @ 2011-11-04 22:30 UTC (permalink / raw) To: Daniel Vetter; +Cc: dri-devel@lists.freedesktop.org On 11/04/2011 04:34 PM, Daniel Vetter wrote: > On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: > >> Hi. >> >> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >> >> Some hardware (vmware's virtual in particular) may not be able to >> pick up the changes from a bo directly, since the cursor data is >> sent though the command stream. Hence we need a notification when >> the cursor image has changed. >> >> Could we *require* that a cursor image change needs to be followed >> by an ioctl call with the flag >> DRM_MODE_CURSOR_BO? >> > On i915 we need the cursor in physical memory for some (old) platforms, > which is seperate storage from the bo backing storage. So we have the same > problem. We've solved it by intercepting pwrite ioctl calls and demanding > that userspace only uses these for cursor updates. Is there a special > reason you can't use such a driver-specific trick? > -Daniel > We have something similar in use today: We snoop DMAs to hardware cursor surfaces, but this gets a bit nasty when apps start to do hardware render to cursor surfaces, and we simply ignore that today. Furthermore, maps rather than pwrites are the common usage-pattern for buffer-backed cursors on vmwgfx, and while it's possible to dirty those buffers based on page-faults, like we do with fb surfaces, we'd rather avoid having to implement and maintain that. I'm not sure whether / how you handle the case of hardware render to cursor surfaces on i915, but it seems to me like if a lot of drivers need to implement driver specific "tricks" to meet the semantics of a generic interface, we should perhaps consider specifying those semantics in a way that helps avoid driver-specific workarounds? /Thomas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 22:30 ` Thomas Hellstrom @ 2011-11-04 22:49 ` Maarten Maathuis 2011-11-04 22:59 ` Thomas Hellstrom 2011-11-05 16:10 ` Daniel Vetter 1 sibling, 1 reply; 13+ messages in thread From: Maarten Maathuis @ 2011-11-04 22:49 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > On 11/04/2011 04:34 PM, Daniel Vetter wrote: >> >> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: >> >>> >>> Hi. >>> >>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >>> >>> Some hardware (vmware's virtual in particular) may not be able to >>> pick up the changes from a bo directly, since the cursor data is >>> sent though the command stream. Hence we need a notification when >>> the cursor image has changed. >>> >>> Could we *require* that a cursor image change needs to be followed >>> by an ioctl call with the flag >>> DRM_MODE_CURSOR_BO? >>> >> >> On i915 we need the cursor in physical memory for some (old) platforms, >> which is seperate storage from the bo backing storage. So we have the same >> problem. We've solved it by intercepting pwrite ioctl calls and demanding >> that userspace only uses these for cursor updates. Is there a special >> reason you can't use such a driver-specific trick? >> -Daniel >> > > We have something similar in use today: We snoop DMAs to hardware > cursor surfaces, but this gets a bit nasty when apps start to do hardware > render to cursor surfaces, and > we simply ignore that today. > > Furthermore, maps rather than pwrites are the common usage-pattern for > buffer-backed cursors on vmwgfx, and while it's possible to dirty those > buffers based on page-faults, like we do with fb surfaces, we'd rather avoid > having to implement and maintain that. > > I'm not sure whether / how you handle the case of hardware render to cursor > surfaces on i915, but it seems to me like if a lot of drivers need to > implement driver specific "tricks" to meet the semantics of a generic > interface, we should perhaps consider specifying those semantics in a way > that helps avoid driver-specific workarounds? > > /Thomas > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > As far as i know nouveau keeps an internal buffer object for the cursor and relies purely on the ioctl to copy the cursor into the actual cursor memory area. So why do you need tricks? -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 22:49 ` Maarten Maathuis @ 2011-11-04 22:59 ` Thomas Hellstrom 2011-11-04 23:20 ` Maarten Maathuis 0 siblings, 1 reply; 13+ messages in thread From: Thomas Hellstrom @ 2011-11-04 22:59 UTC (permalink / raw) To: Maarten Maathuis; +Cc: Thomas Hellstrom, dri-devel@lists.freedesktop.org On 11/04/2011 11:49 PM, Maarten Maathuis wrote: > On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom<thellstrom@vmware.com> wrote: > >> On 11/04/2011 04:34 PM, Daniel Vetter wrote: >> >>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: >>> >>> >>>> Hi. >>>> >>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl: >>>> >>>> Some hardware (vmware's virtual in particular) may not be able to >>>> pick up the changes from a bo directly, since the cursor data is >>>> sent though the command stream. Hence we need a notification when >>>> the cursor image has changed. >>>> >>>> Could we *require* that a cursor image change needs to be followed >>>> by an ioctl call with the flag >>>> DRM_MODE_CURSOR_BO? >>>> >>>> >>> On i915 we need the cursor in physical memory for some (old) platforms, >>> which is seperate storage from the bo backing storage. So we have the same >>> problem. We've solved it by intercepting pwrite ioctl calls and demanding >>> that userspace only uses these for cursor updates. Is there a special >>> reason you can't use such a driver-specific trick? >>> -Daniel >>> >>> >> We have something similar in use today: We snoop DMAs to hardware >> cursor surfaces, but this gets a bit nasty when apps start to do hardware >> render to cursor surfaces, and >> we simply ignore that today. >> >> Furthermore, maps rather than pwrites are the common usage-pattern for >> buffer-backed cursors on vmwgfx, and while it's possible to dirty those >> buffers based on page-faults, like we do with fb surfaces, we'd rather avoid >> having to implement and maintain that. >> >> I'm not sure whether / how you handle the case of hardware render to cursor >> surfaces on i915, but it seems to me like if a lot of drivers need to >> implement driver specific "tricks" to meet the semantics of a generic >> interface, we should perhaps consider specifying those semantics in a way >> that helps avoid driver-specific workarounds? >> >> /Thomas >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> > As far as i know nouveau keeps an internal buffer object for the > cursor and relies purely on the ioctl to copy the cursor into the > actual cursor memory area. So why do you need tricks? > > Because I have a hard time judging whether the Intel implementation (needs tricks) or the Nouveau implementation (doesn't need tricks) should define the semantics of the ioctl, although I would prefer we could all agree on the "doesn't need tricks" semantics and put that down in writing in the drm_mode.h header file. /Thomas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 22:59 ` Thomas Hellstrom @ 2011-11-04 23:20 ` Maarten Maathuis 0 siblings, 0 replies; 13+ messages in thread From: Maarten Maathuis @ 2011-11-04 23:20 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > On 11/04/2011 11:49 PM, Maarten Maathuis wrote: >> >> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom<thellstrom@vmware.com> >> wrote: >> >>> >>> On 11/04/2011 04:34 PM, Daniel Vetter wrote: >>> >>>> >>>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote: >>>> >>>> >>>>> >>>>> Hi. >>>>> >>>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR >>>>> iotcl: >>>>> >>>>> Some hardware (vmware's virtual in particular) may not be able to >>>>> pick up the changes from a bo directly, since the cursor data is >>>>> sent though the command stream. Hence we need a notification when >>>>> the cursor image has changed. >>>>> >>>>> Could we *require* that a cursor image change needs to be followed >>>>> by an ioctl call with the flag >>>>> DRM_MODE_CURSOR_BO? >>>>> >>>>> >>>> >>>> On i915 we need the cursor in physical memory for some (old) platforms, >>>> which is seperate storage from the bo backing storage. So we have the >>>> same >>>> problem. We've solved it by intercepting pwrite ioctl calls and >>>> demanding >>>> that userspace only uses these for cursor updates. Is there a special >>>> reason you can't use such a driver-specific trick? >>>> -Daniel >>>> >>>> >>> >>> We have something similar in use today: We snoop DMAs to hardware >>> cursor surfaces, but this gets a bit nasty when apps start to do hardware >>> render to cursor surfaces, and >>> we simply ignore that today. >>> >>> Furthermore, maps rather than pwrites are the common usage-pattern for >>> buffer-backed cursors on vmwgfx, and while it's possible to dirty those >>> buffers based on page-faults, like we do with fb surfaces, we'd rather >>> avoid >>> having to implement and maintain that. >>> >>> I'm not sure whether / how you handle the case of hardware render to >>> cursor >>> surfaces on i915, but it seems to me like if a lot of drivers need to >>> implement driver specific "tricks" to meet the semantics of a generic >>> interface, we should perhaps consider specifying those semantics in a way >>> that helps avoid driver-specific workarounds? >>> >>> /Thomas >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> >> >> As far as i know nouveau keeps an internal buffer object for the >> cursor and relies purely on the ioctl to copy the cursor into the >> actual cursor memory area. So why do you need tricks? >> >> > > Because I have a hard time judging whether the Intel implementation (needs > tricks) or the Nouveau implementation (doesn't need tricks) should define > the semantics of the ioctl, although I would prefer we could all agree on > the "doesn't need tricks" semantics and put that down in writing in the > drm_mode.h header file. > > /Thomas > > > > I see your point, i certainly prefer the "doesn't need tricks" approach. Maybe allow for some kind of hybrid approach, require the ioctl for every cursor change, but allow drivers to do a kind of lazy implementation that simply attaches the buffer to the hardware and let it handle it. If they want to avoid copying overhead or stuff like that. This would impose some restrictions on what you can do with a cursor buffer after calling the ioctl, specifically you would be required to leave the content alone, except for cursor updates. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-04 22:30 ` Thomas Hellstrom 2011-11-04 22:49 ` Maarten Maathuis @ 2011-11-05 16:10 ` Daniel Vetter 2011-11-07 10:26 ` Thomas Hellstrom 2011-11-11 18:17 ` James Simmons 1 sibling, 2 replies; 13+ messages in thread From: Daniel Vetter @ 2011-11-05 16:10 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: > I'm not sure whether / how you handle the case of hardware render to > cursor surfaces on i915, but it seems to me like if a lot of drivers > need to implement driver specific "tricks" to meet the semantics of > a generic interface, we should perhaps consider specifying those > semantics in a way that helps avoid driver-specific workarounds? We don't handle really hanlde rendering to cursor objects. I think the "require a set_cursor after every cursor bo change" semantic is good, I've just feared that when only vmgfx needs this, no generic kms user will actually implement it. But nouveau seems to require this too, so I think at least for this case reality (and generic kms clients) will play along. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-05 16:10 ` Daniel Vetter @ 2011-11-07 10:26 ` Thomas Hellstrom 2011-11-11 18:17 ` James Simmons 1 sibling, 0 replies; 13+ messages in thread From: Thomas Hellstrom @ 2011-11-07 10:26 UTC (permalink / raw) To: Daniel Vetter; +Cc: dri-devel@lists.freedesktop.org On 11/05/2011 05:10 PM, Daniel Vetter wrote: > On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: > >> I'm not sure whether / how you handle the case of hardware render to >> cursor surfaces on i915, but it seems to me like if a lot of drivers >> need to implement driver specific "tricks" to meet the semantics of >> a generic interface, we should perhaps consider specifying those >> semantics in a way that helps avoid driver-specific workarounds? >> > We don't handle really hanlde rendering to cursor objects. I think the > "require a set_cursor after every cursor bo change" semantic is good, I've > just feared that when only vmgfx needs this, no generic kms user will > actually implement it. But nouveau seems to require this too, so I think > at least for this case reality (and generic kms clients) will play along. > -Daniel > Great. I'll cook up a header file patch with some extra documentation. /Thomas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-05 16:10 ` Daniel Vetter 2011-11-07 10:26 ` Thomas Hellstrom @ 2011-11-11 18:17 ` James Simmons 2011-11-11 19:10 ` Maarten Maathuis 1 sibling, 1 reply; 13+ messages in thread From: James Simmons @ 2011-11-11 18:17 UTC (permalink / raw) To: Daniel Vetter; +Cc: Thomas Hellstrom, dri-devel@lists.freedesktop.org > On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: > > I'm not sure whether / how you handle the case of hardware render to > > cursor surfaces on i915, but it seems to me like if a lot of drivers > > need to implement driver specific "tricks" to meet the semantics of > > a generic interface, we should perhaps consider specifying those > > semantics in a way that helps avoid driver-specific workarounds? > > We don't handle really hanlde rendering to cursor objects. I think the > "require a set_cursor after every cursor bo change" semantic is good, I've > just feared that when only vmgfx needs this, no generic kms user will > actually implement it. But nouveau seems to require this too, so I think > at least for this case reality (and generic kms clients) will play along. I know this is a bit off topic but I see two approaches to the cursor api. One is the nouveau method which is ... drm_gem_object_lookup internal_mmap gem object copy to another internally allocated buffer objec unmap gem object drm_gem_object_unreference_unlocked ... Or the radeon approach ... drm_gem_object_lookup gem_object_pin program cursor location gem_object_unpin drm_gem_object_unreference_unlocked ... What are the pros and cons to each method? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-11 18:17 ` James Simmons @ 2011-11-11 19:10 ` Maarten Maathuis 2011-11-11 19:14 ` Maarten Maathuis 0 siblings, 1 reply; 13+ messages in thread From: Maarten Maathuis @ 2011-11-11 19:10 UTC (permalink / raw) To: James Simmons; +Cc: Thomas Hellstrom, dri-devel@lists.freedesktop.org On Fri, Nov 11, 2011 at 7:17 PM, James Simmons <jsimmons@infradead.org> wrote: > >> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >> > I'm not sure whether / how you handle the case of hardware render to >> > cursor surfaces on i915, but it seems to me like if a lot of drivers >> > need to implement driver specific "tricks" to meet the semantics of >> > a generic interface, we should perhaps consider specifying those >> > semantics in a way that helps avoid driver-specific workarounds? >> >> We don't handle really hanlde rendering to cursor objects. I think the >> "require a set_cursor after every cursor bo change" semantic is good, I've >> just feared that when only vmgfx needs this, no generic kms user will >> actually implement it. But nouveau seems to require this too, so I think >> at least for this case reality (and generic kms clients) will play along. > > I know this is a bit off topic but I see two approaches to the cursor api. > One is the nouveau method which is > > ... > drm_gem_object_lookup > internal_mmap gem object > copy to another internally allocated buffer objec > unmap gem object > drm_gem_object_unreference_unlocked > ... > > Or the radeon approach > > ... > drm_gem_object_lookup > gem_object_pin > program cursor location > gem_object_unpin > drm_gem_object_unreference_unlocked > ... > > What are the pros and cons to each method? > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Copying means you can convert the cursor to another format if needed. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: KMS cursor BO semantics 2011-11-11 19:10 ` Maarten Maathuis @ 2011-11-11 19:14 ` Maarten Maathuis 0 siblings, 0 replies; 13+ messages in thread From: Maarten Maathuis @ 2011-11-11 19:14 UTC (permalink / raw) To: James Simmons; +Cc: Thomas Hellstrom, dri-devel@lists.freedesktop.org On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis <madman2003@gmail.com> wrote: > On Fri, Nov 11, 2011 at 7:17 PM, James Simmons <jsimmons@infradead.org> wrote: >> >>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote: >>> > I'm not sure whether / how you handle the case of hardware render to >>> > cursor surfaces on i915, but it seems to me like if a lot of drivers >>> > need to implement driver specific "tricks" to meet the semantics of >>> > a generic interface, we should perhaps consider specifying those >>> > semantics in a way that helps avoid driver-specific workarounds? >>> >>> We don't handle really hanlde rendering to cursor objects. I think the >>> "require a set_cursor after every cursor bo change" semantic is good, I've >>> just feared that when only vmgfx needs this, no generic kms user will >>> actually implement it. But nouveau seems to require this too, so I think >>> at least for this case reality (and generic kms clients) will play along. >> >> I know this is a bit off topic but I see two approaches to the cursor api. >> One is the nouveau method which is >> >> ... >> drm_gem_object_lookup >> internal_mmap gem object >> copy to another internally allocated buffer objec >> unmap gem object >> drm_gem_object_unreference_unlocked >> ... >> >> Or the radeon approach >> >> ... >> drm_gem_object_lookup >> gem_object_pin >> program cursor location >> gem_object_unpin >> drm_gem_object_unreference_unlocked >> ... >> >> What are the pros and cons to each method? >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > Copying means you can convert the cursor to another format if needed. > > -- > Far away from the primal instinct, the song seems to fade away, the > river get wider between your thoughts and the things we do and say. > Also no worries about strange side effects if people decide to render to the cursor. Although i don't know if this is really an issue. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-11-11 19:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-04 11:59 KMS cursor BO semantics Thomas Hellstrom 2011-11-04 14:36 ` Ilija Hadzic 2011-11-04 14:38 ` Thomas Hellstrom 2011-11-04 15:34 ` Daniel Vetter 2011-11-04 22:30 ` Thomas Hellstrom 2011-11-04 22:49 ` Maarten Maathuis 2011-11-04 22:59 ` Thomas Hellstrom 2011-11-04 23:20 ` Maarten Maathuis 2011-11-05 16:10 ` Daniel Vetter 2011-11-07 10:26 ` Thomas Hellstrom 2011-11-11 18:17 ` James Simmons 2011-11-11 19:10 ` Maarten Maathuis 2011-11-11 19:14 ` Maarten Maathuis
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.