Daniel Stone wrote: > On Thu, May 17, 2007 at 04:08:53PM +0200, ext Frantisek Dufka wrote: >> As for kernel few examples are >> >> - proper YUV420 support in framebuffer update ioctl, stock N770 kernel >> has this broken, fix is easy, would be useful for mplayer > > Sure, I have no problem with this; I guess the best way would be to list > all the patches somewhere as part of a submission (e.g. on a wiki, not > on the list).
Ok, will attach to OS2007on700 tracker https://garage.maemo.org/tracker/?atid=683&group_id=164 and send you a link. BTW I have also added waiting for yyc converter to yuv modes which is not there for N770 kernel with Tornado despite being documented in specs while N800 has the code when the very same bit of NDISP_CTRL_STATUS register tested there is documented as reserved and having default value 0 in my copy of S1D13745 specs (i.e no longer having yyc converter finished bit there). > >> - HW rotation support in framebuffer update ioctl > > As I've said, this patch is conceptually broken. Fixing it so that it > uses the stock standard fbdev API instead of rolling our own is possible > for Hailstorm, at least, but I don't know about Tornado. I'd have to > check. I'm not sure which patch you mean. Do you mean patch that could do this http://lemody.blogspot.com/2005/11/xrandr-o-2.html i.e. fullscreen 180 degree rotation transparent to rest of the system? This should perhaps be really hooked somehow to standard fbdev rotation API but I was thinking about something different. I was thinking about rotation of specific updated rectangle/square i.e. conceptually same thing like turning on pixel doubling flag for specific rectangle update or choosing different pixel color format for specific update. Such rotation feature could be useful and would IMO fit to same place in framebuffer code like the pixel doubling flag and is not related to fb rotation API. Or is there support for specific rectangle rotation while rest of framebuffer stays non-rotated? I guess not because even the manual update mode with rectangle updates is there because of having external video chip with own RAM which is not very common. But anyway, does this mean that N770 kernel is still maintained inside Nokia so there is someone (you) who will accept patches? Of course I can submit it to linux-omap (and I probably will) but current omap tree is not very useful for us, mere mortals, who prefer initfs/rootfs with all its proprietary bits working. > > I'm not sure about this; guess we'd have to dig up the schematics to > find out for sure. I guess getting wider testing would be the easiest > way at this point. You mean someone with different/newer N770 hardware? This would be interesting. I know there are two firmwares for wlan chips, newer N770 kernel supports two differnt LCD display panels and there is even code that suggests some devices have mmc slot capable of 4bit mode. So is there someone in this list with newer HW build than 1602 (see /proc/component_version) who would share dmesg output of boot sequence and would be willing to test kernel and mplayer with tearsync feature? Good candidate is N770 device that loads 3826.arm wlan firmware on boot or have ls041y3 LCD panel (mine loads 3825.arm firmware and have lph8923 panel). > > You might want to just port the whole omapfb back to .16, as there have > been a ton of changes. That's what I was trying to avoid. Are those features (framebuffer in SRAM, more planes) useful for N770 device? I guess not very much. Perhaps best for verifying that it is not my bug is booting 2.6.18 with custom rootfs instead. Regards, Frantisek _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
