Re: [AD] X hardware cursors fix

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sat, 2005-03-19 at 17:49 +0100, Evert Glebbeek wrote:
> On Saturday 19 March 2005 16:51, Elias Pschernig wrote:
> > > I don't like gfx_capabilities & GFX_SYSTEM_CURSOR though.  
> > > "Capabilities" should be about the gfx driver's potential, not what it 
> > > is doing at present.  Of course, gfx_capabilities & 
> > > GFX_CAN_TRIPLE_BUFFER and gfx_capabilities & GFX_HW_CURSOR violate this 
> > > already.
> > 
> > Yes, I see. So we would have a static field in each driver with its
> > capabilities. Having GFX_CAN_TRIPLE_BUFFER in there would merely tell if
> > the driver can principally do it, not if it is currently enabled.
> > 
> > GFX_CAN_TRIPLE_BUFFER we can't change for 4.2.0, because it already was
> > in 4.0.0. But GFX_HW_CURSOR and GFX_SYSTEM_CURSOR we could still fix.
> 
> No, we cannot, at least not for GFX_HW_CURSOR: this has been in Allegro as 
> far back as I can remember. I don't think it ever did anything except in 
> DOS and Windows GDI (in the latter case, it's even a lie that it's a 
> hardware cursor as far as I recall it's a hack to make Allegro think it is 
> one), but it was there.
> I don't much like the construction either, but considering that 
> GFX_HW_CURSOR was already there, adding GFX_SYSTEM_CURSOR in the same 
> manner seemed at least API-consistent.

Ah, I missed that, I thought both were added together with the other
changes. Hm.. but how would you use them, without
enable_hardware_cursor?

> > Add show_os_cursor(), so in the case where the user just wants a HW/OS
> > cursor, there is no confusion. A simple return value tells if it
> > suceeded or not. No need for any flags, since Allegro isn't in any way
> > involved into drawing the mouse.
> > 
> > The show_mouse API, OTOH, means Allegro takes over mouse drawing. But
> > since the user must be prepared for the software mouse in any case, what
> > if we simply drop these 3 functions:
> > 
> > enable_hardware_cursor/disable_hardware_cursor/select_mouse_cursor
> 
> You need enable_hardware_cursor because hardware cursors (that includes 
> system cursors) are incompatible with an infinite range of mouse mickeys: 
> you can't have both, and Allegro's former behavior guarenteed it at least 
> in X11.

I see, didn't think about this at all. Well, just using a hardware
cursor with enable_hardware_cursor certainly looks broken to me, since
the bitmap parameter to show_mouse would be ignored. But there's no need
for it if we have show_os_cursor (or show_hardware_cursor, would really
be the same).

> I think we discussed this sometime last summer, or whenever the issue first 
> came up. I think the consensus at that time was that we shouldn't break 
> backward compatibility by changing Allegro's behavior with respect to 
> mouse mickeys (despite the fact that it already doesn't quite work in 
> windowed mode in Windows anyway)

I know, I thought myself it was best to hide the different mouse cursors
from the user back then, or at least, didn't pay all that much
attention. But now after using hardware cursors, I find the
single-simple-function approach much better than super-imposing it over
show_mouse() (even if that actually was already in the original DOS
drivers..).

> . I'm not saying we can't recondider that 
> (I think it makes sense to reconsider it, considering the bloody mess the 
> X11 mouse driver is because of it), but it's a bit late now to do this for 
> the 4.1/4.2 branch.

Yes. But if we don't have show_os_cursor in 4.2.0, we force users to do
this weird enable_hardware_cursor/show_mouse/gfx_capabilities&WHATEVER
thing.

> Ideally, the API would look something like `show this or such system native 
> mouse pionter' or `use this bitmap as a mouse pointer'. The complication 

Exactly :) show_os_cursor would be the first (selecting aither an OS
native cursor or Allegro bitmap), set_mouse_cursor_bitmap would allow
changing that Allegro bitmap - that's just what I want and how it works
with my patch (in X11) :)

> sets in if we want to use a bitmap as a mouse pointer but have the OS draw 
> it anyway, which is preferable if possible. Hence the distinction between 
> `software cursor', `hardware cursor' and `system cursor'. The first two 
> are historic and the latter is new. It would make sense to have a 
> `software cursor' and a `hardware cursor' that can be either a custom 
> bitmap or a system default pointer I suppose, but this does not fit 
> cleanly into the old mouse cursor API.

I see, I didn't know that hardware cursors are historic. So then I
propose to just supercede them with system cursors, and deprecate the
hardware cursor concept. As the example in previous mail showed, all it
means is a single if in user code to not call show_mouse if the hardware
cursor was already sucessfully displayed.

> 
> In short, while the mouse drawing code could be far simpler and cleaner 
> than it is now, making it so is quite a bit more work than it seems.
> 

Yes, like always :| But still, it already sort of works in X11.. hm,
I'll look some more at the code in the next days in any case.

-- 
Elias Pschernig