#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)
Change History (36)
by , 12 years ago
comment:1 by , 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 , 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 , 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 , 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.
comment:6 by , 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 , 12 years ago
Attachment: | 0001-set-fHardwareCursorEnabled-false-in-case-we-can-t-se.patch added |
---|
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 , 12 years ago
patch: | 0 → 1 |
---|
by , 12 years ago
Attachment: | 0002-show-the-HW-cursor-if-it-was-set-hide-it-if-not.patch added |
---|
show the HW cursor if set, hide it if not
comment:8 by , 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 , 12 years ago
Cc: | added |
---|
comment:10 by , 12 years ago
CCed looncraz as he activated hardware cursor support back in November 2012.
comment:11 by , 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 , 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.)
follow-up: 14 comment:13 by , 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
follow-up: 15 comment:14 by , 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.
comment:15 by , 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
comment:16 by , 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:18 by , 12 years ago
Priority: | normal → high |
---|
comment:19 by , 11 years ago
Milestone: | R1 → R1/beta1 |
---|
Moving this to the current next release milestone.
comment:20 by , 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 , 11 years ago
Blocking: | 10756 added |
---|
comment:22 by , 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 , 11 years ago
Attachment: | nvidia.settings added |
---|
~/config/settings/kernel/drivers/nvidia.settings that disables the hardware cursor for nvidia cards.
comment:23 by , 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 , 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 , 11 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 , 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 , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Patch applied in hrev48185. Untested since I don't have hw cursor support here.
comment:29 by , 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 :)
syslog