Re: cursor handling and updates inside DRM
Stephane Marchesin escreveu: On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote: Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. Care to elaborate ? What you describe here sounds like an implementation-specific issue, more than an issue with KMS. Okay, I lied here ;) The reason of the cursor jumping is not the number of context switches. Dave helped me to identify the real reason. Try to call a xrandr instance and move the mouse with kernel modesetting. xrandr will do DDC communication which will blocked X in the kernel. With my implementation of the X server using a separate thread to take care the input events this is _reduced_ because signals is not used to wake up the devices. Moreover, with the handling and update of the cursor inside the kernel all would work perfectly smooth (in fact I tried it with my proof-of-concept and it was confirmed). Thanks you, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Tiago Vignatti wrote: [0] https://bugs.freedesktop.org/attachment.cgi?id=17545 This doc says that it improves the heavy-load behavior, but I'm failing to see it. Can you be more specific? Sure. The old code would assume mouse delta = speed. Of course, this assumption is valid only as long as mouse updates are equally spaced in time. Under heavy load, the devices (or the kernel/whoever) would accumulate the delta. The old accel then uses that to accelerate. With polynomial accel or high accel factors, this leads to greatly exaggerated cursor movement. It drove me nuts so I decided to do something about it. The new code doesn't fall for that. Admittedly there is still cursor jumping, but at least it jumps where you'd expect it to be. I'll try explaining that better in the docs. -Simon - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Jesse Barnes wrote: Right, and it's actually fairly common in other OSes. It sounds like the biggest chunk of additional code will be dealing with acceleration; I'm not sure how complex the latest algorithms are... Also input transformation is an unknown, but it's a bit dubious anyway... If it's coming that way, OK. The accel stuff isn't _that_ big. The meat is ~500 LOC, and you can get comparable precision with less effort. However for a kernel mechanism, I'd say an arbitrary acceleration profile (think connecting dots to mod your mouse resonse) is a must-have IMO. Also, the 'raw' device data should be available in parallel, e.g. for gesture detection. Input transform is mainly for absolute devices, if I got that right. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Thursday, July 10, 2008 9:14:20 pm Dave Airlie wrote: Right, and it's actually fairly common in other OSes. It sounds like the biggest chunk of additional code will be dealing with acceleration; I'm not sure how complex the latest algorithms are... Also input transformation is an unknown, but it's a bit dubious anyway... Input transform shouldn't matter, as long as you aren't warping the cursor around corners etc.. the mouse should still move on the screen the same, Yeah, talked with Keith about this yesterday; I was worried input transform might actually constrain the cursor to a given trap or something. Since that's not the case there should be no problem. its only when you click or drag something with it that the X server needs to transform it to get to the right window. There's also cursor warping, but that's easy enough to handle with an ioctl. Keep up the good work, Tiago! Thanks, Jesse - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? signature.asc Description: Digital signature - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Daniel Stone escreveu: On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? Yes, Daniel. This was my first thought. Now I'm trying to discuss with you how we can distribute this things between X, drm and kernel. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Thu, Jul 10, 2008 at 2:55 PM, Tiago Vignatti [EMAIL PROTECTED] wrote: Daniel Stone escreveu: On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? Yes, Daniel. This was my first thought. Now I'm trying to discuss with you how we can distribute this things between X, drm and kernel. The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Cheers Jakob. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Simon Thum escreveu: But all this in the kernel is an impedance mismatch to me. What could it buy us we don't have today? Improve heavy-load behavior -- no jumping pointer. (BTW, your mouse acceleration proposal [0] doesn't do it at all.) Cheers, [0] https://bugs.freedesktop.org/attachment.cgi?id=17545 This doc says that it improves the heavy-load behavior, but I'm failing to see it. Can you be more specific? -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Hi Jakob, Jakob Bornecrantz escreveu: The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote: Hi Jakob, Jakob Bornecrantz escreveu: The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. Care to elaborate ? What you describe here sounds like an implementation-specific issue, more than an issue with KMS. Stephane - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote: Simon Thum escreveu: But all this in the kernel is an impedance mismatch to me. What could it buy us we don't have today? Improve heavy-load behavior -- no jumping pointer. (BTW, your mouse acceleration proposal [0] doesn't do it at all.) Cheers, [0] https://bugs.freedesktop.org/attachment.cgi?id=17545 This doc says that it improves the heavy-load behavior, but I'm failing to see it. Can you be more specific? Right, and it's actually fairly common in other OSes. It sounds like the biggest chunk of additional code will be dealing with acceleration; I'm not sure how complex the latest algorithms are... Also input transformation is an unknown, but it's a bit dubious anyway... Jesse - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
On Fri, Jul 11, 2008 at 1:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote: Simon Thum escreveu: But all this in the kernel is an impedance mismatch to me. What could it buy us we don't have today? Improve heavy-load behavior -- no jumping pointer. (BTW, your mouse acceleration proposal [0] doesn't do it at all.) Cheers, [0] https://bugs.freedesktop.org/attachment.cgi?id=17545 This doc says that it improves the heavy-load behavior, but I'm failing to see it. Can you be more specific? Right, and it's actually fairly common in other OSes. It sounds like the biggest chunk of additional code will be dealing with acceleration; I'm not sure how complex the latest algorithms are... Also input transformation is an unknown, but it's a bit dubious anyway... Input transform shouldn't matter, as long as you aren't warping the cursor around corners etc.. the mouse should still move on the screen the same, its only when you click or drag something with it that the X server needs to transform it to get to the right window. Dave. Jesse ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Tiago Vignatti wrote: Daniel Stone escreveu: On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? Yes, Daniel. This was my first thought. Now I'm trying to discuss with you how we can distribute this things between X, drm and kernel. As I view it, a hypothetical driver combo could do this today. It would be in need to somehow sync its operation to the server mechanisms, but surely doable. But all this in the kernel is an impedance mismatch to me. What could it buy us we don't have today? - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
