From: Jon Smirl <hidden> Date: 2005-06-11 04:57:29
James has indicated that the soft_cursor only works with fbconsole and
it won't work from user space. This means that soft_cursor is in the
way of using a hardware cursor from user space. This patch removes
soft_cursor from all of the drivers. So if the driver doesn't support
a hardware cursor fb_cursor is NULL.
I also fixed the three drivers with hardware implementation. These
drivers had cases where the hardware cursor had an error and then
returned the software one instead. Now they return -ENODEV when they
can't use the hardware one.
In console/bitlbt.c I made this change:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
The effect of all of this is the make a clear path for getting to
hardware cursors without triggering the soft_cursor fallback.
Triggering of the fallback was moved into fb_console. This also lets
me remove the softcursor module from memory when fb_console is not
loaded.
Give this a try and let me know what you think.
--
Jon Smirl
jonsmirl@gmail.com
From: James Simmons <hidden> Date: 2005-06-11 06:15:41
Ug no. I see in the future more drivers using hardware cursors instead.
We would be carry around extra software cursor code in the the framebuffer
console all the time. We need to properly fix the cursor code. Unfortunely
that will take more work. In the mean time please encourage people to
support hardware cursors. Even crappy cards have hardware cursors most of
the time.
On Sat, 11 Jun 2005, Jon Smirl wrote:
James has indicated that the soft_cursor only works with fbconsole and
it won't work from user space. This means that soft_cursor is in the
way of using a hardware cursor from user space. This patch removes
soft_cursor from all of the drivers. So if the driver doesn't support
a hardware cursor fb_cursor is NULL.
I also fixed the three drivers with hardware implementation. These
drivers had cases where the hardware cursor had an error and then
returned the software one instead. Now they return -ENODEV when they
can't use the hardware one.
In console/bitlbt.c I made this change:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
The effect of all of this is the make a clear path for getting to
hardware cursors without triggering the soft_cursor fallback.
Triggering of the fallback was moved into fb_console. This also lets
me remove the softcursor module from memory when fb_console is not
loaded.
Give this a try and let me know what you think.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
From: Jon Smirl <hidden> Date: 2005-06-11 13:10:24
On 6/11/05, James Simmons [off-list ref] wrote:
Ug no. I see in the future more drivers using hardware cursors instead.
We would be carry around extra software cursor code in the the framebuffer
console all the time. We need to properly fix the cursor code. Unfortunely
that will take more work. In the mean time please encourage people to
support hardware cursors. Even crappy cards have hardware cursors most of
the time.
The way things are now I can't use the hardware cursors without
triggering the software one. The way I changed it user space (when
the interface is finished) will get hardware or nothing. fbconsole
will get the same hardware or nothing, but if nothing it implements a
software cursor.
The question here is who is responsible for generating a software
cursor, is it the hardware driver's responsibility or the app using
the system? fbconsole would be considered an app using the system.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
From: Jon Smirl <hidden> Date: 2005-06-11 13:23:24
On 6/11/05, James Simmons [off-list ref] wrote:
Ug no. I see in the future more drivers using hardware cursors instead.
We would be carry around extra software cursor code in the the framebuffer
console all the time. We need to properly fix the cursor code. Unfortunely
that will take more work. In the mean time please encourage people to
support hardware cursors. Even crappy cards have hardware cursors most of
the time.
Also, I didn't delete the fb_cursor field. I just removed all of the
assignments of .fb_cursor = soft_cursor. The field is still there and
defaulting to null, except in the three drivers with hardware cursors
where it is set.
For a driver to implement software cursors it has to know the location
of the scanout buffer, scanbuffer format, etc. I not sure if all of
this is always know for user space apps. The hardware cursor doesn't
need as much info about the framebuffer.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
James has indicated that the soft_cursor only works with fbconsole and
it won't work from user space. This means that soft_cursor is in the
way of using a hardware cursor from user space. This patch removes
soft_cursor from all of the drivers. So if the driver doesn't support
a hardware cursor fb_cursor is NULL.
I also fixed the three drivers with hardware implementation. These
drivers had cases where the hardware cursor had an error and then
returned the software one instead. Now they return -ENODEV when they
can't use the hardware one.
In console/bitlbt.c I made this change:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
The effect of all of this is the make a clear path for getting to
hardware cursors without triggering the soft_cursor fallback.
Triggering of the fallback was moved into fb_console. This also lets
me remove the softcursor module from memory when fb_console is not
loaded.
Give this a try and let me know what you think.
This patch corrupts some comments in drivers/video/amifb.c.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
From: Jon Smirl <hidden> Date: 2005-06-11 22:01:46
On 6/11/05, Geert Uytterhoeven [off-list ref] wrote:
This patch corrupts some comments in drivers/video/amifb.c.
This should fix it. I touched up a few other places with unintended
changes. I don't think all of the fbdev files have been authored using
the same codepage.
--
Jon Smirl
jonsmirl@gmail.com
On 6/11/05, Geert Uytterhoeven [off-list ref] wrote:
quoted
This patch corrupts some comments in drivers/video/amifb.c.
This should fix it. I touched up a few other places with unintended
Thx!
changes. I don't think all of the fbdev files have been authored using
the same codepage.
The original ones were ISO-8859-1 or -15 (anyone who puts EURO-signs in GPLed
source code? :-). But these days the preferred encoding is UTF-8.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
From: Jon Smirl <hidden> Date: 2005-06-16 01:34:06
Are there still issues with this patch?
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: Antonino A. Daplas <hidden> Date: 2005-06-16 03:26:44
On Thursday 16 June 2005 09:34, Jon Smirl wrote:
Are there still issues with this patch?
Maybe. A few drivers will set the fb_cursor field to either
soft_cursor or the driver-specific cursor function, depending
on the kernel boot options or setting of the var.accel flag.
The changes required are probably minor.
Tony
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-06-16 03:37:17
On 6/15/05, Antonino A. Daplas [off-list ref] wrote:
On Thursday 16 June 2005 09:34, Jon Smirl wrote:
quoted
Are there still issues with this patch?
Maybe. A few drivers will set the fb_cursor field to either
soft_cursor or the driver-specific cursor function, depending
on the kernel boot options or setting of the var.accel flag.
I think there were three driver implementing hardware cursors.
I tried to keep them working, they only needed minor touchups.
If they had fallbacks to the software cursor I removed those and
returned an error instead. Instead fbconsole will get the error and
switch to software cursor. If HW cursors are going to work from user
space they can't contain SW cursor fallbacks.
The patch should move softcursor.c into the fbconsole subdirectory but
I can't figure out how to do that with git yet.
The changes required are probably minor.
Tony
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: James Simmons <hidden> Date: 2005-06-21 00:08:01
On 6/15/05, Antonino A. Daplas [off-list ref] wrote:
quoted
On Thursday 16 June 2005 09:34, Jon Smirl wrote:
quoted
Are there still issues with this patch?
Maybe. A few drivers will set the fb_cursor field to either
soft_cursor or the driver-specific cursor function, depending
on the kernel boot options or setting of the var.accel flag.
I think there were three driver implementing hardware cursors.
I tried to keep them working, they only needed minor touchups.
If they had fallbacks to the software cursor I removed those and
returned an error instead. Instead fbconsole will get the error and
switch to software cursor. If HW cursors are going to work from user
space they can't contain SW cursor fallbacks.
The patch should move softcursor.c into the fbconsole subdirectory but
I can't figure out how to do that with git yet.
quoted
The changes required are probably minor.
Tony
I agree we should not fall back to the software cursor when the hardware
cursor fails. Do we really want to eliminate the cursor from the device
interface if it is not a hardware cursor? Shouldn't the cursor always
work? That is the question.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-06-21 00:31:19
On 6/20/05, James Simmons [off-list ref] wrote:
I agree we should not fall back to the software cursor when the hardware
cursor fails. Do we really want to eliminate the cursor from the device
interface if it is not a hardware cursor? Shouldn't the cursor always
work? That is the question.
I don't think there really is a choice here. Fbdev has to implement
the hardware cursor. The software one is application specific.
fbconsole and X implement it completely differently. I don't think
there is a way to implement a general software cursor.
fbdev provides hardware or nothing
if no hardware cursor, cursor is up to app
fbconsole and X then provide two different fallback schemes.
For example I don't think we have enough info to implement X's
software cursor in the fbdev driver. We would need some way to know
when X is updating the screen via paint or buffer swaps. Wouldn't that
be a total mess for fbdev to track and a new API would be needed.
We just never noticed the problem before since only one client
(fbconsole) was using the cursor. Current X is programming the
hardware cursor from user space.
After this change it would probably be cleaner to just eliminate the
softcursor module and compile softcursor into fbconsole. softcursor.c
would be moved to the fbconsole subdir if you can figure out how to
tell git to do a mv. But we can always save these changes for later.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: James Simmons <hidden> Date: 2005-06-24 00:10:04
For example I don't think we have enough info to implement X's
software cursor in the fbdev driver. We would need some way to know
when X is updating the screen via paint or buffer swaps. Wouldn't that
be a total mess for fbdev to track and a new API would be needed.
I was pondering this and you are right. For the software cursor you
need to blend the cursor image with what data is in the framebuffer at that
location. If we have a concurrent thread that updates that area of the
framebuffer then we would have to notify the cursor of the change to
update that region of the screen with proper data. There is no clean way
to do this.
Now I was thinking instead of a massive move of the the software
cursor we add a flag FBINFO_HWACCEL_CURSOR to tell us if we are using a
hardware cursor. This way for the sysfs interface you can test to see if
it is a hardware cursor and only allow userland to access a hardware
cursor. Here is a patch for that. People please try it out.
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: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-06-24 12:26:16
On 6/23/05, James Simmons [off-list ref] wrote:
Now I was thinking instead of a massive move of the the software
cursor we add a flag FBINFO_HWACCEL_CURSOR to tell us if we are using a
hardware cursor. This way for the sysfs interface you can test to see if
it is a hardware cursor and only allow userland to access a hardware
cursor. Here is a patch for that. People please try it out.
Your code will work, but it is conceptually what we want to do?
Software cursors are application specific. The soft cursor implemented
in fbdev really belongs to fbconsole. If we get another in-kernel
user with a different update pattern (maybe they use the GPU) they
will want a different soft cursor. Shouldn't we just move the current
soft cursor into fbconsole? Given that software cursors are
application specific fbdev should not contain one.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: James Simmons <hidden> Date: 2005-06-24 16:17:29
quoted
Now I was thinking instead of a massive move of the the software
cursor we add a flag FBINFO_HWACCEL_CURSOR to tell us if we are using a
hardware cursor. This way for the sysfs interface you can test to see if
it is a hardware cursor and only allow userland to access a hardware
cursor. Here is a patch for that. People please try it out.
Your code will work, but it is conceptually what we want to do?
Software cursors are application specific. The soft cursor implemented
in fbdev really belongs to fbconsole. If we get another in-kernel
user with a different update pattern (maybe they use the GPU) they
will want a different soft cursor. Shouldn't we just move the current
soft cursor into fbconsole? Given that software cursors are
application specific fbdev should not contain one.
The only reason I'm against that is then when the developer with the
different update pattern will create a new fbconsole. We could end up
with several fbconsoles. I really like to keep it down to one. So I rather
deal with several cursor implementation instead of several fbconsoles.
Also remember that the software cursor is generically wrapped around the
the imageblit function. Since imageblit is independent of the update
pattern we will be okay.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-06-24 16:27:36
On 6/24/05, James Simmons [off-list ref] wrote:
quoted
quoted
Now I was thinking instead of a massive move of the the software
cursor we add a flag FBINFO_HWACCEL_CURSOR to tell us if we are using a
hardware cursor. This way for the sysfs interface you can test to see if
it is a hardware cursor and only allow userland to access a hardware
cursor. Here is a patch for that. People please try it out.
Your code will work, but it is conceptually what we want to do?
Software cursors are application specific. The soft cursor implemented
in fbdev really belongs to fbconsole. If we get another in-kernel
user with a different update pattern (maybe they use the GPU) they
will want a different soft cursor. Shouldn't we just move the current
soft cursor into fbconsole? Given that software cursors are
application specific fbdev should not contain one.
The only reason I'm against that is then when the developer with the
different update pattern will create a new fbconsole. We could end up
with several fbconsoles. I really like to keep it down to one. So I rather
deal with several cursor implementation instead of several fbconsoles.
Also remember that the software cursor is generically wrapped around the
the imageblit function. Since imageblit is independent of the update
pattern we will be okay.
To address your concern, leave softcursor as an fbdev module. But we
do need to remove all of those .fb_cursor = softcursor from all of the
fbdev modules. As long as those are there we can only have one
softcursor implementation.
Then any in-kernel user does this:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
I want to remove the fallback to softcursor logic from fbdev, I don't
care if the softcursor modules stays part of fbdev, it's the fallback
logic that doesn't belong in the drivers. There is no need for all of
the drivers to reference softcursor.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: James Simmons <hidden> Date: 2005-06-24 17:13:30
To address your concern, leave softcursor as an fbdev module. But we
do need to remove all of those .fb_cursor = softcursor from all of the
fbdev modules. As long as those are there we can only have one
softcursor implementation.
Does this patch work for you? It reports to userland that no cursor is
avaiable if the fbdev driver is using the software cursor.
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: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-06-24 17:25:59
Why are you trying to preserve all of the ".fb_cursor = soft_cursor,"
assignments in the drivers? What purpose do they serve that can't be
handled by a simple test like this:
Then any in-kernel user does this:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: James Simmons <hidden> Date: 2005-07-01 23:32:30
Why are you trying to preserve all of the ".fb_cursor = soft_cursor,"
assignments in the drivers? What purpose do they serve that can't be
handled by a simple test like this:
Then any in-kernel user does this:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
I don't want to make a patch that touches all the drivers. Th epatch I
posted is a nice simple patch. If there are no other arguments against it
I like to submit it to Andrew.
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: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
should be something like this. I can come with a good patch if you want
(now it's just a mail hack)
if (ACCEL(dinfo, info)) {
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN |
FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_IMAGEBLIT;
} else {
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
}
+ if (dinfo->hwcursor)
+ info->flags |= FBINFO_HWACCEL_CURSOR;
Regards
Sylvain
James Simmons a écrit:
quoted hunk
quoted
Why are you trying to preserve all of the ".fb_cursor = soft_cursor,"
assignments in the drivers? What purpose do they serve that can't be
handled by a simple test like this:
Then any in-kernel user does this:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
I don't want to make a patch that touches all the drivers. Th epatch I
posted is a nice simple patch. If there are no other arguments against it
I like to submit it to Andrew.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/mach64_cursor.c fbdev-2.6/drivers/video/aty/mach64_cursor.c
{
struct fb_info *info;
struct intelfb_info *dinfo;
- int i, j, err, dvo;
+ int i, err, dvo;
int aperture_size, stolen_size;
struct agp_kern_info gtt_info;
int agp_memtype;
@@ -841,13 +837,6 @@
if (bailearly == 5)
bailout(dinfo);
- for (i = 0; i < 16; i++) {
- j = color_table[i];
- dinfo->palette[i].red = default_red[j];
- dinfo->palette[i].green = default_grn[j];
- dinfo->palette[i].blue = default_blu[j];
- }
-
if (bailearly == 6)
bailout(dinfo);
#define FBINFO_HWACCEL_XPAN 0x1000 /* optional */
#define FBINFO_HWACCEL_YPAN 0x2000 /* optional */
#define FBINFO_HWACCEL_YWRAP 0x4000 /* optional */
+#define FBINFO_HWACCEL_CURSOR 0x8000 /* required */
#define FBINFO_MISC_USEREVENT 0x10000 /* event request
from userspace */
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: Jon Smirl <hidden> Date: 2005-07-02 00:28:16
On 7/1/05, James Simmons [off-list ref] wrote:
I don't want to make a patch that touches all the drivers. Th epatch I
posted is a nice simple patch. If there are no other arguments against it
I like to submit it to Andrew.
But we agreed that having the drivers fallback to the softcursor is
the wrong general thing to do since it only works for fbconsole. Why
do we want to keep code in place when we agree that it is not needed?
All it does is add clutter to the driver code.
You don't need to make the patch, I already made it for you.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: Jon Smirl <hidden> Date: 2005-07-02 00:56:57
Another way to think of this, let's make another member variable
.fb_hwcursor. When the driver has a hardware cusor is sets
.fb_hwcursor. If you want to use the software cursor use the exisiting
.fb_cursor.
If you think about it every driver is going to have the exact same
assignment .fb_cursor = soft_cursor. If every driver is going to have
exactly the same assignment, why do we need the variable?
It's the existence of the hardware cursor that varies from driver to
driver, that's the one we need the variable for.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
should be something like this. I can come with a good patch if you want
(now it's just a mail hack)
if (ACCEL(dinfo, info)) {
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN |
FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_IMAGEBLIT;
} else {
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
}
+ if (dinfo->hwcursor)
+ info->flags |= FBINFO_HWACCEL_CURSOR;
Regards
Sylvain
James Simmons a écrit:
quoted
quoted
Why are you trying to preserve all of the ".fb_cursor = soft_cursor,"
assignments in the drivers? What purpose do they serve that can't be
handled by a simple test like this:
Then any in-kernel user does this:
/* First try the hardware cursor */
if (info->fbops->fb_cursor)
err = info->fbops->fb_cursor(info, &cursor);
/* if that doesn't exist or didn't work, use the software one */
if (err)
soft_cursor(info, &cursor);
I don't want to make a patch that touches all the drivers. Th epatch I
posted is a nice simple patch. If there are no other arguments against it
I like to submit it to Andrew.
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/aty/mach64_cursor.c fbdev-2.6/drivers/video/aty/mach64_cursor.c
{
struct fb_info *info;
struct intelfb_info *dinfo;
- int i, j, err, dvo;
+ int i, err, dvo;
int aperture_size, stolen_size;
struct agp_kern_info gtt_info;
int agp_memtype;
@@ -841,13 +837,6 @@
if (bailearly == 5)
bailout(dinfo);
- for (i = 0; i < 16; i++) {
- j = color_table[i];
- dinfo->palette[i].red = default_red[j];
- dinfo->palette[i].green = default_grn[j];
- dinfo->palette[i].blue = default_blu[j];
- }
-
if (bailearly == 6)
bailout(dinfo);
#define FBINFO_HWACCEL_XPAN 0x1000 /* optional */
#define FBINFO_HWACCEL_YPAN 0x2000 /* optional */
#define FBINFO_HWACCEL_YWRAP 0x4000 /* optional */
+#define FBINFO_HWACCEL_CURSOR 0x8000 /* required */
#define FBINFO_MISC_USEREVENT 0x10000 /* event request
from userspace */
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-07-23 05:06:23
On Saturday 02 July 2005 08:56, Jon Smirl wrote:
Another way to think of this, let's make another member variable
.fb_hwcursor. When the driver has a hardware cusor is sets
.fb_hwcursor. If you want to use the software cursor use the exisiting
.fb_cursor.
If you think about it every driver is going to have the exact same
assignment .fb_cursor = soft_cursor. If every driver is going to have
exactly the same assignment, why do we need the variable?
It's the existence of the hardware cursor that varies from driver to
driver, that's the one we need the variable for.
Is this resolved? I tend to agree with Jon. Let's just remove all
references to soft_cursor from all drivers, and let fbcon_cursor() fall back
to soft_cursor when xxxfb_cursor() is absent. It is a lot cleaner and saner
this way, and although it touches all drivers, it is a singe logical change,
so it's acceptable.
Also, I think it might be preferable to have 2 cursor hooks, one
is fbcon-specific, and the other is for use only in userspace, which needs
to be more comprehensive. Or if a single but comprehensive cursor API is
preferred, then we just adapt fbcon_cursor to use the more powerful
cursor API.
So, anyone want to propose a cursor API for fbdev, that is both usable by
fbcon and userspace?
Tony
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-07-23 15:41:31
This not currently resolved.
From user space we can have two interfaces
1) the current ioctl one
2) the new stuff in sysfs. If the hardware cursor is there you get a sysfs
attribute named cursor. write x,y to it to move the cursor around. I'll add
the sysfs support as soon as we decide on the interface.
I'm still at OLS. Missed seeing both of you at KS. fbdev was discussed and
Linus went with Benh's proposal to move the modesetting API to user space.
Obviously this will have a lot of impact on fbdev.
On 7/23/05, Antonino A. Daplas [off-list ref] wrote:
On Saturday 02 July 2005 08:56, Jon Smirl wrote:
quoted
Another way to think of this, let's make another member variable
.fb_hwcursor. When the driver has a hardware cusor is sets
.fb_hwcursor. If you want to use the software cursor use the exisiting
.fb_cursor.
If you think about it every driver is going to have the exact same
assignment .fb_cursor = soft_cursor. If every driver is going to have
exactly the same assignment, why do we need the variable?
It's the existence of the hardware cursor that varies from driver to
driver, that's the one we need the variable for.
Is this resolved? I tend to agree with Jon. Let's just remove all
references to soft_cursor from all drivers, and let fbcon_cursor() fall
back
to soft_cursor when xxxfb_cursor() is absent. It is a lot cleaner and
saner
this way, and although it touches all drivers, it is a singe logical
change,
so it's acceptable.
Also, I think it might be preferable to have 2 cursor hooks, one
is fbcon-specific, and the other is for use only in userspace, which needs
to be more comprehensive. Or if a single but comprehensive cursor API is
preferred, then we just adapt fbcon_cursor to use the more powerful
cursor API.
So, anyone want to propose a cursor API for fbdev, that is both usable by
fbcon and userspace?
Tony
From: James Simmons <hidden> Date: 2005-07-25 16:34:17
1) the current ioctl one
Defunct.
2) the new stuff in sysfs. If the hardware cursor is there you get a sysfs
attribute named cursor. write x,y to it to move the cursor around. I'll add
the sysfs support as soon as we decide on the interface.
I was playing with that a bit.
I'm still at OLS. Missed seeing both of you at KS. fbdev was discussed and
Linus went with Benh's proposal to move the modesetting API to user space.
Obviously this will have a lot of impact on fbdev.
I don't have any money to go to such events :-( Looks like fbdev is going
away completly :-< We will need embedded graphics libraries to boot a
machine in the future. I seen this coming and thats why my motivation for
development keeps dropping. I suggest they make a big diff to remove the
whole system.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Jon Smirl <hidden> Date: 2005-07-25 16:46:28
On 7/25/05, James Simmons [off-list ref] wrote:
quoted
1) the current ioctl one
Defunct.
quoted
2) the new stuff in sysfs. If the hardware cursor is there you get a sysfs
attribute named cursor. write x,y to it to move the cursor around. I'll add
the sysfs support as soon as we decide on the interface.
I was playing with that a bit.
quoted
I'm still at OLS. Missed seeing both of you at KS. fbdev was discussed and
Linus went with Benh's proposal to move the modesetting API to user space.
Obviously this will have a lot of impact on fbdev.
I don't have any money to go to such events :-( Looks like fbdev is going
away completly :-< We will need embedded graphics libraries to boot a
machine in the future. I seen this coming and thats why my motivation for
development keeps dropping. I suggest they make a big diff to remove the
whole system.
It is a long way from Linus telling BenH to go ahead and having a
replacement system in the kernel. My bet is that userspace mode
setting only happens for a couple of chips. I don't see a lot of
people jumping up to replace the existing system. I was pushing to
keep fbdev the way it is but without either of the maintainers there
to defend fbdev it is a hard sell.
If you write a paper for OLS, get it accepted and present it; the
sponsors will probably pay your airfare. Hotels can be had for
$40/night. Work on Ted to get an invite to Kernel Summit and then give
him four months notice that you need airfare and you'll probably get
it.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click