| 00:08 | _rmk_ | dv_: nope, hardware seems to be the norm now |
| 14:47 | dv_ | _rmk_: I dont understand why. what is the gain? the cursor is just a small icon |
| 14:49 | shesselba | dv_: it is HW overlay, you don't have to redraw backround when you move the cursor |
| 14:50 | dv_ | but is it some special kind of overlay? is there something like a "special cursor overlay"? |
| 14:50 | dv_ | if so, I wonder why its special, and why it cannot be just yet another regular ARGB one |
| 14:52 | shesselba | it has an SRAM to store the overlay bitmap, that is limited to 64x32 or 32x64 ARGB pixels |
| 14:54 | dv_ | shesselba: yeah, thats my point. it sounds like an extra software and hardware effort that does not seem to be worth it to me |
| 14:54 | shesselba | that was _rmk_'s concern in the first place |
| 14:55 | dv_ | I dont understand why HW manufacturers would even do that, given that the overall trend is towards general-purpose chips |
| 14:55 | dv_ | but anyway, just being curious. |
| 14:59 | shesselba | on-chip SRAM is expensive, that is why it is limited in size |
| 14:59 | shesselba | and to be honest ARGB cursors are ridiculous |
| 15:04 | _rmk_ | dv_: if you have sensible hardware like i915, then the hardware cursor can be stored in video RAM as just another buffer object, and you can update it by just writing into video memory in a standard format with no conversion from what X provides. |
| 15:05 | _rmk_ | dv_: and you can move it around the screen by appending commands to the card's command queue which get processed on the next vsync - including to coordinates which take it beyond the visible area (if partially visible you'll get a partially visible cursor) |
| 15:06 | dv_ | this sounds a lot like how 3D rendering operates |
| 15:07 | _rmk_ | dv_: if you have sucky embedded hardware which cut corners - like the Armada stuff - then it has limited size, it also can't be programmed with any part of it outside of the visible area... which makes it suck from the CPU offload point of view |
| 15:08 | dv_ | i often wonder how efficient it would be to draw the entire UI with EGL and GLES only |
| 15:08 | _rmk_ | on x86 hardware, its also normal for the mouse position to be read inside a SIGIO handler in X, and for the update of its position via hardware to be done also in that signal handler |
| 15:08 | _rmk_ | which means the mouse moves even if the X server is busy with other stuff |
| 15:08 | dv_ | apple seems to do it on the iphone, but then again, they control the entire platform |
| 15:09 | dv_ | true, I have noticed that |
| 15:09 | shesselba | _rmk_: but it is a plus from a bus access point-of-view, although cursor size compared to HD video is almost neglectible |
| 15:10 | dv_ | yeah. this reminds me of the argument in favor of point sprites in opengl |
| 15:10 | dv_ | bus access is reduced to 1 vertex (instead of 4 or 6) |
| 15:10 | shesselba | I guess when marvell bought the ip HD video wasn't on the list ;) |
| 15:12 | dv_ | hehe, yeah |
| 15:12 | dv_ | but that means that the driver I am currently using draws the cursor in software, no? because from what I gather, hw cursor was broken |