Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#9261 closed bug (fixed)

Problem with cursor on hrev 44952 gcc4h

Reported by: Hubert Owned by: axeld
Priority: high Milestone: R1/beta1
Component: Servers/app_server Version: R1/Development
Keywords: hardware cursor Cc: looncraz
Blocked By: Blocking: #9631, #10483, #10756
Platform: x86

Description

When I run system I have normal white cursor but when I start e.g Vision Haiku freeze on 2-3 sec and I have black pud.

Attachments (7)

syslog (255.9 KB ) - added by Hubert 12 years ago.
syslog
screenshot1.jpeg (95.2 KB ) - added by Hubert 12 years ago.
before
screenshot2.jpeg (325.3 KB ) - added by Hubert 12 years ago.
after
0001-set-fHardwareCursorEnabled-false-in-case-we-can-t-se.patch (906 bytes ) - added by Ziusudra 12 years ago.
Allows for switching from HW curosr back to SW cursor, but the HW cursor image does not move (though it is drawn correctly).
0002-show-the-HW-cursor-if-it-was-set-hide-it-if-not.patch (887 bytes ) - added by Ziusudra 12 years ago.
show the HW cursor if set, hide it if not
AHWI.diff (4.2 KB ) - added by Ziusudra 12 years ago.
not a proper patch
nvidia.settings (3.2 KB ) - added by humdinger 11 years ago.
~/config/settings/kernel/drivers/nvidia.settings that disables the hardware cursor for nvidia cards.

Download all attachments as: .zip

Change History (36)

by Hubert, 12 years ago

Attachment: syslog added

syslog

by Hubert, 12 years ago

Attachment: screenshot1.jpeg added

before

by Hubert, 12 years ago

Attachment: screenshot2.jpeg added

after

comment:1 by Hubert, 12 years ago

Ups. I no noticed that there are no feet on the screens. I made a new snapshot with mouse cursor but it looks normal(white) on screenshot o.O

comment:2 by anevilyak, 12 years ago

Keywords: hardware added

This is due to the recent addition of hardware cursor support. I see the same issue here and disabling the hardware cursor in my graphics driver brings things back to normal.

comment:3 by Hubert, 12 years ago

Can I disable hardware cursor in system? If not, this option should be possibly as the same as the appearance of the mouse pointer.

comment:4 by Ziusudra, 12 years ago

I'm seeing this with a Nvidia GeForce 7300 GT (G73) and a 45145 4H build.

Seen with Vision when it tries to use its cursors for links and dividers. Also seen with Icon-O-Matic when it tries to use its eye-dropper cursor. (Also, the hot-spot of the eye-dropper cursor seems to be in opposite corner than what it should be.)

I can't get it to happen with any of the "standard" cursors, say the one Web+ and Tracker use. It seems to be limited to custom ones.

It happens the first time trying to use any of those cursors, and after that the cursor wont change unless it is to one of the other of these.

The transparent pixels are white, some pixels are black, and others appear to be inverted.

Last edited 12 years ago by Ziusudra (previous) (diff)

comment:5 by Ziusudra, 12 years ago

Cortex and Playground also have custom cursors that do this.

comment:6 by Ziusudra, 12 years ago

Some notes:

/src/add-ons/accelerants/nvidia (and radeon) can only SetCursorShape not SetCursorBitmap. This is why it is only happening with "custom" cursors, the app server cursors have no shape data to set.

/src/servers/app/drawing/AccelerantHWInterface::SetCursor does not set fHardwareCursorEnabled to false if it cannot set the HW cursor. So the app server cursors stop working once a HW cursor is set and the cursor only changes when a different custom cursor is set.

(Off topic: It seems to me that AccelerantHWInterface::SetCursor should try to SetCursorBitmap before SetCursorShape. Though I don't know if it is possible to have the option of both.)

I don't know why the colors are wrong.

by Ziusudra, 12 years ago

Allows for switching from HW curosr back to SW cursor, but the HW cursor image does not move (though it is drawn correctly).

comment:7 by Ziusudra, 12 years ago

patch: 01

by Ziusudra, 12 years ago

show the HW cursor if set, hide it if not

comment:8 by Ziusudra, 12 years ago

With these two patches four problems remain:

The colors: tranparent is white, white is black, and black is inverse of whatever pixel is under that point.

When initially setting a cursor the app server is also drawing the cursor and not erasing it until that region is redrawn for some other reason.

The hot spot coordinates are switched. This is most evident with Icon-O-Matic's dropper cursor.

When setting a HW cursor it will be in the position of the last displayed HW cursor until the next MoveCursorTo.

For anyone using Nvidia the drivers, they have an optional settings file which has an option for disabling the HW cursor. (http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings or http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/nvidia_gpgpu/nvidia_gpgpu.settings)

comment:9 by korli, 12 years ago

Cc: looncraz added

comment:10 by korli, 12 years ago

CCed looncraz as he activated hardware cursor support back in November 2012.

comment:11 by looncraz, 12 years ago

I posted a patch on the mailing list on 12/3

http://files.looncraz.net/HWCursor-Update-2.patch

It changes a few things:

Prefers SetBitmapCursor if offered, corrects clipping issues, and goes a small way into improving performance.

Please try it and get back to me. I have a partially functional HW cursor on radeon_hd (all I see is a dot - but that dot works perfectly, for what it's worth...).

--The loon

comment:12 by Ziusudra, 12 years ago

This diff gives me a proper cursor. Based on looncraz's patch with some changes: switches the hot spot coords, shows the cursor after succesfully setting it, fixes the masks and comments on how the BeOS masks differ.

Still leaves the one cursor image drawn by app server and having the wrong initial position. (And I guess the fact that the app server cursors have no shape data.)

comment:13 by looncraz, 12 years ago

I missed the most important update patch in my last comment:

http://files.looncraz.net/HWCursor-Update.patch You will want both.

The update above changes the priority of hardware cursors to favor bitmap cursors first and foremost among some other changes to address an observed issue.

Wish I had time to look at this more... need to find a better keyboard, first...

--The loon

in reply to:  13 ; comment:14 by Ziusudra, 12 years ago

Replying to looncraz:

I missed the most important update patch in my last comment:

http://files.looncraz.net/HWCursor-Update.patch You will want both.

You are mistaken, both are not wanted (and won't apply together anyway.) The only functional difference between these is the crash bug you fixed. (See: http://www.freelists.org/post/haiku-development/Hardware-cursor-TEST-patch,5)

Only the "HWCursor-Update-2.patch" diff (or my AHWI.diff) should be used.

in reply to:  14 comment:15 by looncraz, 12 years ago

Replying to Ziusudra:

http://files.looncraz.net/HWCursor-Update.patch You will want both.

You are mistaken, both are not wanted (and won't apply together anyway.) The only functional difference between these is the crash bug you fixed. (See: http://www.freelists.org/post/haiku-development/Hardware-cursor-TEST-patch,5)

Only the "HWCursor-Update-2.patch" diff (or my AHWI.diff) should be used.

The second update was created after the first, my memory said they were related.

Ill have to create a new patch to bring back the changes from the first update patch. It doesnt address the bug here, anyway (the second patch does that). The first patch, which will now need to be recreated, was to change the app_server to allow accelerants which only support bitmap cursors to also be able to support legacy cursors without any extra work.

It also, however, included a degree of awareness for the previous cursor acceleration state in order to cleanup the software cursor region when moving to the hardware cursor... I will look at it more closely in the next couple of days.

--The loon

by Ziusudra, 12 years ago

Attachment: AHWI.diff added

not a proper patch

comment:16 by Ziusudra, 12 years ago

This new diff fixes everything for me. The hardware cursor now works seamlessly on my Nvidia GeForce 7300 GT (G73).

Can patchify if desired, tommorow though, nearly bedtime.

I'm not sure about holding the two locks at the same time, could that be a problem?

comment:17 by anevilyak, 12 years ago

Blocking: 9631 added

(In #9631) Duplicate of #9261.

comment:18 by anevilyak, 12 years ago

Priority: normalhigh

comment:19 by mmadia, 11 years ago

Milestone: R1R1/beta1

Moving this to the current next release milestone.

comment:20 by AlienSoldier, 11 years ago

I got the problem with a NVIDIA GeForce4 MX 440 with AGP 4X 64mb and an ATI 3D rage xl.

First encountered the problem with Vision and Beshare (the pane resizing cursor).

Another thing i noticed with the 3D rage xl (i have yet to make complete test with the other hardware) is that it also interact with overlay acceleration. Using VLC (the normal R5 one, 0.86) i was freezing the screen (at each try), i think this was at the moment i was going full screen but perhaps also just from having it running with something in overlay in it. So starting vision was asking for a reboot because the system was unusable at that point.

comment:21 by humdinger, 11 years ago

Blocking: 10756 added

(In #10756) Turns out, this was already reported in #9261. Thanks, anevilyak, for notifying me...

comment:22 by humdinger, 11 years ago

For completeness, I attach the file ~/config/settings/kernel/drivers/nvidia.settings that disables the "hardcursor". It's a work around until the issue is solved.

by humdinger, 11 years ago

Attachment: nvidia.settings added

~/config/settings/kernel/drivers/nvidia.settings that disables the hardware cursor for nvidia cards.

comment:23 by AlienSoldier, 11 years ago

Even if the software cursor solved the problem for the last week, i now stumbled on the problem of cursor again with Vision. So either the card stayed in hardware cursor mode even if my config file state software or the problem just happen less often in software mode.

comment:24 by humdinger, 11 years ago

Funnily, back when my notebook still worked, I've seen the same thing with Vision again too. I unfairly blamed scanty's NES emulator or what it was... :-)
I've seen it for about 2 weeks, I guess.

comment:25 by pistooli, 10 years ago

I have the same problem with an ASUS NVIDIA 7300GT when I start Vision. 2-3 minutes freeze, then ugly cursor. The attached nvidia.seetings seems to be a good work around.

comment:26 by AlienSoldier, 10 years ago

Capacitor plague on my normal P4, i now need to use the intel entry server. Can't use my Nvidia card it it, stuck with the onboard video said to be 0x4752 Rage XL PCI (ATI/AMD). How is it possible to disable hardware mouse on this one also? Computer is pretty much useless for me in this state. Until hardware cursor is solved on all driver, it should be removed imho.

Seem the hang with full screen is not related to overlay, it does it also with media player (not just VLC) and it does not have overlay with that card. As soon as full screen is enabled, the video continue but the screen no longer move. Once video done, i am stuck with a full screen frozen i can't remove in front of the desktop.

comment:27 by pulkomandy, 10 years ago

Resolution: fixed
Status: newclosed

Patch applied in hrev48185. Untested since I don't have hw cursor support here.

comment:28 by pulkomandy, 10 years ago

Blocking: 10483 added

(In #10483) Duplicate of #9261.

comment:29 by AlienSoldier, 10 years ago

Rapid check with BePDF (a cursor modifying app) show that the problem seem solved on the Rage XL PCI i use right now.

Much appreciated :)

Note: See TracTickets for help on using tickets.