Author Topic: Pxa270 Overlay Dev Funding (Read 11257 times)

danboid · « **on:** June 15, 2006, 12:01:11 pm »

I just posted this in a thread under the pdaXrom forum and omro suggested I ask somewhere else.

"The thing that worries me is kernel development. It seems that within OZ it is only RP who really does anything. I BADLY want to see proper pxa270 overlay support which is as good as or surpasses 2.4's bvdd but it seems that this isn't a priority for RP. RP, if you're reading, may I may make a suggestion? If we raise some funding would you be able to concentrate on this (and pxa270 freq scaling) so we can get this major obstacle, for cxxxx/OZ users, out of the way? Or is there anybody else who thinks they might be up to this task?"

I promise this is the LAST TIME I make a thread on this subject as I'm sure that with this I've exhausted all possibilities and I would rather not irritate the OZ devs with my constant pleading. I know it would happen eventually but I'm too impatient

Da_Blitz · « **Reply #1 on:** June 16, 2006, 04:37:20 am »

If you check the OZ site and look under the developers tab there is a link to pay pal

rpurdie · « **Reply #2 on:** June 16, 2006, 11:08:27 am »

Quote

"The thing that worries me is kernel development. It seems that within OZ it is only RP who really does anything. I BADLY want to see proper pxa270 overlay support which is as good as or surpasses 2.4's bvdd but it seems that this isn't a priority for RP. RP, if you're reading, may I may make a suggestion? If we raise some funding would you be able to concentrate on this (and pxa270 freq scaling) so we can get this major obstacle, for cxxxx/OZ users, out of the way? Or is there anybody else who thinks they might be up to this task?"

I don't read the forums but someone mentioned this was here. I do intend to look at these issues and its a question of time, not money. There are a lot of demands on my time and I'm juggling them as best I can.

There are a lot of things that go on behind the scenes that people don't realise and its been pointed out to me that perhaps I should illustrate some of them. Yesterday I probably spent about 6 hours working out why the 2.6.17-rc kernels didn't have working PCMCIA when reading CF cards on the Zaurus. This turned out to be a trivial problem with one of the Zaurus patches and is now resolved (with the patch being pulled from the upcomming OZ 3.5.4.1 release as well although it didn't seem to cause a problem under 2.6.16).

The advantage of this behind the scenes work is when 2.6.17 ships in the next few days, I can instantly provide a kernel which should live up to the standards set by 2.6.16. Having a working cutting edge mainline kernel is important as I will want to develop the overlay code against mainline so we can get it merged and reduce the maintenance load.

The night before I debugged the console rotation code to find out why logos didn't display properly on rotated framebuffers. The fix will be made in mainline and we have a copy of that fix now in use in the forthcomming OZ 3.5.4.1 release along with working logos.

Recently I also spent time applying the IRQ patches that testing was requested for on linux-arm-kernel. I found problems, worked with the author to fix them and am now happy that when there are merged after 2.6.17 comes out, the Zaurus will be unaffected.

This is not a complaint and I don't mind doing this but perhaps you can begin to see how finding a large free chunk of development time for overlay support is difficult. Progress on the Zaurus kernels has always been slow and steady and overlay support will happen! When we do implement it, it will be done properly, get into mainline and hopefully continue to work in many kernel versions thereafter.

danboid · « **Reply #3 on:** June 16, 2006, 06:49:03 pm »

Thanks for the update RP- I appreciate being updated on the state of Linux's Z support. Have you got a blog?

Da_Blitz · « **Reply #4 on:** June 17, 2006, 08:58:47 am »

Yeah alot of the stuff you do is incredible and i would really like to see a blow by blow acount of what you did, have done and are doing

Stilgar · « **Reply #5 on:** August 19, 2006, 10:56:31 am »

I can't emphasise enough how important on the 2.6 kernels is... It's been a real mess with the old 2.4 kernels, and I've tried compiling some modules.
Just keep up the good work... I'm sure we'll see hardware acceleration sometime.

adf · « **Reply #6 on:** August 19, 2006, 04:34:27 pm »

LOL I just wote about this very thing in the oz paid support thread.

Would this situation change any if there were a bounty, I think not. Will OZ benefit from abounty system where issues clearly of great impprt to users go unresolved despite a bounty?

Not to denigrate the work beong done. Just pinting out that money doesn't ways change things; and that this might be a source of frustration to would be donors

Da_Blitz · « **Reply #7 on:** August 21, 2006, 02:28:02 am »

well it does seem to be a time limited thing rather than money, if it helps then it helps thogh

personally i like the patches like the IRQ stuff as i have had the Z carsh on me an a couple of occasions and it always seems to be every second OZ release that is buggy

i am intrested in the technical aspects of how it does work, is the problem how to interface to the overlay or just how to present it to the programs as i noted that people are not happy with how the pdaxrom patches were implemented and havent tried to find out why that was so

adf · « **Reply #8 on:** August 21, 2006, 03:05:09 am »

sure, the more generally available the info, the better. I was mostly on about the bounty sustem in OZ (or pdax dor that matter) the stuff most discussed in the why doesn't xyz work type threads is the difficult stuff-- since the easier stuff tends to get done more quickly. I7m afraid that a bounty system will reflect this--- creating the most excitement and demand where the slowest results are made. I'm not sure if the rdeault is healthy.

Lurker · « **Reply #9 on:** October 02, 2006, 03:35:30 pm »

HRW has recently made a test kernel available with PXAFB Overlay, among other features. See the [TESTING Request] kernel update for OpenZaurus 3.5.4.1 thread on the openzaurus-devel mailing list. There is an amusing snippet of conversation at the end of his post...

danboid · « **Reply #10 on:** October 02, 2006, 04:39:18 pm »

I'm speechless! Thanks for pointing that out Lurker!

So the big question now of course is who is going to step forward and code a pxa overlay output driver for mplayer? Whatever happened to atty?

Hrw · « **Reply #11 on:** October 02, 2006, 04:46:10 pm »

The funny thing in it is that pdaX had pdafb overlay support since beta4 and NO ONE wrote application for pdaX which will support it on Zaurus...

Lurker · « **Reply #12 on:** October 02, 2006, 07:08:17 pm »

Danboid,
I get the impression that you have been wanting PXAFB overlay support in OZ so that zpsx could be ported to OZ. zodttd's recent post in the PSX Running on the Zaurus thread leaves me with doubts, though:

Quote

I plan on making 2.4 kernel builds for pdaXrom, cacko, and OZ. In that order. smile.gif
If performance is decent on the 2.6 kernels, I'll get builds for pdaXrom and OZ. But since from what I'm aware of, they still lack BVDD modules for video acceleration. They have overlays but that doesn't help in my case.

I am thoroughly confused... Could someone please provide a simple explanation of bvdd, overlays, frame buffers and other concepts related to PXA video processing?

danboid · « **Reply #13 on:** October 03, 2006, 03:11:38 am »

Of course I can't wait to see zpsx running under a QVGA, SDL console on OZ, which is what this new kernel should allow (once SDL supports pxafb, I'd presume) but getting mplayer patched to support it is much more important. I'd imagine X would need to be patched too.

pdaX beta4 had kernel support for the pxa overlays, but by all accounts beta4 and the new pdax release are still very buggy so that is likely the reason no-one has modified anything to work with it. The other explanation would be that no-one knows how- where is the pxafb kernel interface documented, should anybody step up to the mplayer/SDL pxafb challenge? Has the programmer just got to read through the kernel source atm?

So, when zodttd was saying that the pxa overlay support lagged behind bvdd he was talking about pdaX beta4's implementation. I wonder how different the OZ overlay code is? Is it faster? I guess we won't know until SDL, X and/or mplayer know how to take advantage of it.

So yeah, someone needs to explain whats going on here as I've probably just caused more confusion with this post

koen · « **Reply #14 on:** October 03, 2006, 03:59:03 am »

Quote

The funny thing in it is that pdaX had pdafb overlay support since beta4 and NO ONE wrote application for pdaX which will support it on Zaurus...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142879\"][{POST_SNAPBACK}][/a][/div]

That's inherent to the oesf community, whine a lot, but do nothing and whine some more.

News:

Author Topic: Pxa270 Overlay Dev Funding (Read 11257 times)