Closed Bug 1082892 Opened 10 years ago Closed 7 years ago

Draw a cursor when a mouse is being used

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cjones, Unassigned)

References

Details

(Whiteboard: [ft:conndevices])

Attachments

(4 files, 1 obsolete file)

EventHub sends us "hover move" events for mousemoves, but gonk widgetry ignores them. The forthcoming patch has widget use those events to draw a simple cursor. The impl only works with BasicCompositor for the moment, GL will be added when GL compositor is ready.
Do you happen to know if we get hover-move events with any "normal" touch screens? If so, we should probably guard the cursor-drawing with a pref.
Attachment #8505174 - Flags: review?(mwu)
Hover move events happen with buggy touchscreen drivers. Doing this will discourage vendors from writing such drivers, so we should leave such a thing on by default.
I think GeckoPointerController is the right class to hack if you want to add support. It also can figure out if the cursor should be drawn based on input activity.
Do you want to do that here or can we defer to a followup? I'd like to upstream this asap but it's not absolutely essential.
Comment on attachment 8505174 [details] [diff] [review] Draw a mouse cursor when HOVER_MOVE events are being generated We can't land this patch as-is because its dependency can't land. So RPi folks will have to continue applying it manually until we can switch to GL and write an alternative patch. I'll leave this bug open for the followup GL impl though.
Attachment #8505174 - Flags: review?(mwu) → review-
This patch or bug 1082894 was broken by a recent change, apparently something to do with a vsync observer.
Nope, just an mq juggling problem.
Attachment #8505174 - Attachment is obsolete: true
Attachment #8518540 - Flags: review-
Hi MWU, I'm trying to make this bug continued. Basically, the idea is the same as attached patch. (instead of returning here [1] for AMOTION_EVENT_ACTION_HOVER_MOVE, catch it and assign with a new action type). Now the screen position (x,y) is able to be obtained, but I'm not quite understand where to get the cursor drawn. Though there's AOSP PointerController/SpriteController in current code base (under widget/gonk/libui/), but in order to reduce the dependency, I'm not willing to use them. My 1st question is when StartRemoteDrawing() is called ? (Is it for 2nd screen drawing ?) I assumed that I can get a drawtarget by calling StartRemoteDrawing() directly, and invoking several FillRect() calls, then calling EndRemoteDrawing(). This is supposed to be done in Compositor thread, right ? [1] https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/widget/gonk/nsAppShell.cpp#755 I'll do an experiment for above, just wondering if anyone can provide me guidance earlier to eliminate my doubt. Thanks
Flags: needinfo?(mwu)
A experimental patch to draw a rectangle as a cursor on gonk platform. (Sorry there're some debugging message for me to track the flow.) I think we should handle the machinery by implementing 1. a capability of loading pre-defined cursor(.ico) as system cursor on gonk platform, and 2. implementing a capability of replacing the cursor by web API (css?) due to a customization by each website. We should remove as much dependency as possible from android's PointerController & SpriteController.
Flags: needinfo?(mwu)
This patch needs to be rebased, it does not apply on current tree.
Rebased on top of git head 26b29ca8671ffe50f9fe1be9869076a690b3c414
I base on git head d946d2f1e51830f11931ff6a3c2fe34017572075 to follow Kilik Kuo's patch. 1. fix bug: sometimes cursor can't be updated on screen 2. draw cursor while dragging mouse 3. according to plug in/out event to determine drawing cursor. 4. according to check box status of settings/developer to drawing cursor
Whiteboard: [ft:conndevices]
blocking-b2g: --- → 2.6+
Hi Farmer, Please help to raise b2g48 uplift request. Thanks
Flags: needinfo?(fatseng)
I will land it to TV 2.6 and created a bugzilla to track it. (Bug 1270701)
Flags: needinfo?(fatseng)
No longer blocks: 1260649
blocking-b2g: 2.6+ → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: