From: James Simmons <hidden> Date: 2005-08-07 02:35:04
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/mach64_cursor.c fbdev-2.6/drivers/video/aty/mach64_cursor.c
@@ -242,7 +238,7 @@staticchar*mode=NULL;module_param(accel,bool,S_IRUGO);-MODULE_PARM_DESC(accel,"Enable console acceleration");+MODULE_PARM_DESC(accel,"Enable hardware acceleration");module_param(vram,int,S_IRUGO);MODULE_PARM_DESC(vram,"System RAM to allocate to framebuffer in MiB");module_param(voffset,int,S_IRUGO);
@@ -1704,7 +1704,8 @@|FBINFO_HWACCEL_YPAN|FBINFO_HWACCEL_COPYAREA|FBINFO_HWACCEL_FILLRECT-|FBINFO_HWACCEL_IMAGEBLIT;+|FBINFO_HWACCEL_IMAGEBLIT+|FBINFO_HWACCEL_CURSOR;/* Accel seems to not work properly on NV30 yet...*/if((par->riva.Architecture==NV_ARCH_30)||noaccel){
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Andrew Morton <hidden> Date: 2005-08-07 04:29:14
James Simmons [off-list ref] wrote:
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
Can this change break existing apps?
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Jon Smirl <hidden> Date: 2005-08-07 04:41:49
On 8/7/05, Andrew Morton [off-list ref] wrote:
James Simmons [off-list ref] wrote:
quoted
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
Can this change break existing apps?
This change is not agreed too yet. Antonio and I are proposing a
different solution.
http://comments.gmane.org/gmane.linux.fbdev.devel/7118
The alternate solution takes into account that fbconsole is the only
user of softcursor and moves softcursor into console. fbdev drivers
then only expose a cursor entry point if they have a hardware cursor.
If they don't the entry point is NULL.
Nether solution should break existing apps since the existing
softcursor scheme was broken from user space and unusable.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-07 10:35:15
James Simmons wrote:
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
I don't really like this change. I prefer Jon's proposal of setting
fbops->fb_cursor = NULL and moving softcursor.c to drivers/video/console.
This will slash > 200 lines of source code and several bytes from the kernel
image size. Plus it's cleaner.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-07 23:17:06
James Simmons wrote:
quoted
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
I don't really like this change. I prefer Jon's proposal of setting
fbops->fb_cursor = NULL and moving softcursor.c to drivers/video/console.
This will slash > 200 lines of source code and several bytes from the kernel
image size. Plus it's cleaner.
One change at a time. If you want to properly do cursor in fbcon then just
moving softcursor there is not the answer. What if you have a driver that
has software image blit and hardware fillrect. You want to have fbcon use
the hardware fillrect to draw the cursor using xor mode. See the problem
is more than just moving softcursor.c. Softcursor.c should go away
completely.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-07 23:19:47
On Sat, 6 Aug 2005, Andrew Morton wrote:
James Simmons [off-list ref] wrote:
quoted
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
Can this change break existing apps?
No. No one uses the sysfs for the cursro yet.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-07 23:25:46
This change is not agreed too yet. Antonio and I are proposing a
different solution.
http://comments.gmane.org/gmane.linux.fbdev.devel/7118
The alternate solution takes into account that fbconsole is the only
user of softcursor and moves softcursor into console. fbdev drivers
then only expose a cursor entry point if they have a hardware cursor.
If they don't the entry point is NULL.
Nether solution should break existing apps since the existing
softcursor scheme was broken from user space and unusable.
That is too big a change at one time and moving soft_cursor to fbcon is a
partial solution. See my other email. I don't want to touch every driver
at this point!! First prevent anyone from using soft cursor from userland.
Second fix fbcon version of the cursor. That mean doing more than just
moving the softcursor into fbcon. Third as drivers are updated remove the
soft cursor hooks. It will not break anything.
P.S
When I first started out I sent giant patches that impacted alot of
things. People got upset. Please don't repeat my mistakes with giant
patches that impact every driver.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-08 00:59:32
James Simmons wrote:
quoted
James Simmons wrote:
quoted
This patch forbids the cursor use from userland. The reason is that the
cursor area could be altered by a another process and the current system
doesn't handle syncing those updates.
I don't really like this change. I prefer Jon's proposal of setting
fbops->fb_cursor = NULL and moving softcursor.c to drivers/video/console.
This will slash > 200 lines of source code and several bytes from the kernel
image size. Plus it's cleaner.
One change at a time. If you want to properly do cursor in fbcon then just
moving softcursor there is not the answer. What if you have a driver that
See the patch again, there's only one logical change. And the intent of the
patch was never to support userspace cursor.
has software image blit and hardware fillrect. You want to have fbcon use
Then the driver sets fbops->fb_cursor with its own version that does
fillrect instead of imageblit.
I think you're still trying to overload fbops->fb_cursor. These drawing
functions in info->fbops (fb_imageblit, fb_fillrect, fb_copyarea and
fb_cursor) are for fbcon use _only_. They cannot be used in userspace
because of the inherent limitations of the code, and it depends on fields
that are internal to fbdev/fbcon (ie pseudo_palette). And even if you make it
work, I doubt it will be efficient code. Remember that the fbcon hooks were
written in such a way so that we can have a very fast console, but it
sacrifices userspace compatibility.
If you want to add userspace support for hardware cursors then you have to
create another API. If you don't want another API, then forget about userspace
support. Overloading fbops->fb_cursor is not the answer.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-08 17:35:40
What is wrong with brekaing this patch into smaller pieces????????????
I'm not getting a answer!!!!! As I said no giant patches that tocuh every
driver.
quoted
has software image blit and hardware fillrect. You want to have fbcon use
Then the driver sets fbops->fb_cursor with its own version that does
fillrect instead of imageblit.
No. fb_cursor is only used for a hardware cursor case.
If you want to add userspace support for hardware cursors then you have to
create another API. If you don't want another API, then forget about userspace
support. Overloading fbops->fb_cursor is not the answer.
So fbops->fb_cursor will not be used at all for the console?
Look the patch I sent is small and doesn't interfere with many drivers. It
does stop your desires either. Personally softcursor should go away.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Jon Smirl <hidden> Date: 2005-08-08 17:59:59
On 8/8/05, James Simmons [off-list ref] wrote:
What is wrong with brekaing this patch into smaller pieces????????????
I'm not getting a answer!!!!! As I said no giant patches that tocuh every
driver.
quoted
quoted
has software image blit and hardware fillrect. You want to have fbcon use
Then the driver sets fbops->fb_cursor with its own version that does
fillrect instead of imageblit.
No. fb_cursor is only used for a hardware cursor case.
quoted
If you want to add userspace support for hardware cursors then you have to
create another API. If you don't want another API, then forget about userspace
support. Overloading fbops->fb_cursor is not the answer.
So fbops->fb_cursor will not be used at all for the console?
fbconsole check to see if fbops->fb_cursor is not null, if it is not
null it uses the hardware cursor. Otherwise it uses it's internal
softcursor implementation.
Look the patch I sent is small and doesn't interfere with many drivers. It
does stop your desires either. Personally softcursor should go away.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-08 18:16:10
quoted
So fbops->fb_cursor will not be used at all for the console?
fbconsole check to see if fbops->fb_cursor is not null, if it is not
null it uses the hardware cursor. Otherwise it uses it's internal
softcursor implementation.
See my other email about drivers have a hwcursor flag to turn hardware
cursor off and on.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: James Simmons <hidden> Date: 2005-08-09 02:04:08
quoted
What is wrong with brekaing this patch into smaller pieces????????????
I'm not getting a answer!!!!! As I said no giant patches that tocuh every
driver.
quoted
quoted
has software image blit and hardware fillrect. You want to have fbcon use
Then the driver sets fbops->fb_cursor with its own version that does
fillrect instead of imageblit.
No. fb_cursor is only used for a hardware cursor case.
And what happens if the driver does not have support for a hardware cursor?
quoted
quoted
If you want to add userspace support for hardware cursors then you have to
create another API. If you don't want another API, then forget about userspace
support. Overloading fbops->fb_cursor is not the answer.
So fbops->fb_cursor will not be used at all for the console?
You're getting it backwards. fbops->fb_cursor is for the console. If you want
userspace hardware cursor, then we need a new API. It's not something that I
want, just a fact. Look at the code. Remember, I wrote the orginal fb_cursor
code, so I know its limitations. The sole purpose was to replace the 2.4
permanently blinking block and to allow users to have a choice of using an
underline or block cursor.
But to overload fbops->fb_cursor for use in userspace will just introduce new
headaches and will be painful to debug.
quoted
Look the patch I sent is small and doesn't interfere with many drivers. It
does stop your desires either. Personally softcursor should go away.
And force all maintainers to write forhardware cursor support? Even X doesn't have
that 100% support. Might as well remove cfbimageblit, cfbfillrect and
cfbcopyarea too, if that's what you want.
What I mean is soft_cursor shouldn't be bounds to fbops->fb_cursor. Since
no one understands what I'm trying to say I will create a nice patch to
show you what I mean. Okay!!!!!!!
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-10 01:35:42
James Simmons wrote:
What is wrong with brekaing this patch into smaller pieces????????????
I'm not getting a answer!!!!! As I said no giant patches that tocuh every
driver.
quoted
quoted
has software image blit and hardware fillrect. You want to have fbcon use
Then the driver sets fbops->fb_cursor with its own version that does
fillrect instead of imageblit.
No. fb_cursor is only used for a hardware cursor case.
And what happens if the driver does not have support for a hardware cursor?
quoted
If you want to add userspace support for hardware cursors then you have to
create another API. If you don't want another API, then forget about userspace
support. Overloading fbops->fb_cursor is not the answer.
So fbops->fb_cursor will not be used at all for the console?
You're getting it backwards. fbops->fb_cursor is for the console. If you want
userspace hardware cursor, then we need a new API. It's not something that I
want, just a fact. Look at the code. Remember, I wrote the orginal fb_cursor
code, so I know its limitations. The sole purpose was to replace the 2.4
permanently blinking block and to allow users to have a choice of using an
underline or block cursor.
But to overload fbops->fb_cursor for use in userspace will just introduce new
headaches and will be painful to debug.
Look the patch I sent is small and doesn't interfere with many drivers. It
does stop your desires either. Personally softcursor should go away.
And force all maintainers to write forhardware cursor support? Even X doesn't have
that 100% support. Might as well remove cfbimageblit, cfbfillrect and
cfbcopyarea too, if that's what you want.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf