OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: 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
-
If you check the OZ site and look under the developers tab there is a link to pay pal
-
"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.
-
Thanks for the update RP- I appreciate being updated on the state of Linux's Z support. Have you got a blog?
-
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
-
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.
-
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
-
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
-
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.
-
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 (http://sourceforge.net/mailarchive/forum.php?thread_id=30632812&forum_id=11924) thread on the openzaurus-devel (http://sourceforge.net/mailarchive/forum.php?forum_id=11924) mailing list. There is an amusing snippet of conversation at the end of his post...
-
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?
-
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...
-
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 (https://www.oesf.org/forums/index.php?showtopic=19045&st=75#) in the PSX Running on the Zaurus (https://www.oesf.org/forums/index.php?showtopic=19045) thread leaves me with doubts, though:
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?
-
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
-
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.
-
nice, you can manage an ignore list on this board.
[My Controls]->[Manage Ignored Users]
-
nice, you can manage an ignore list on this board.
[My Controls]->[Manage Ignored Users]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142943\"][{POST_SNAPBACK}][/a][/div]
I'm missing an 'add all' option
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142942\"][{POST_SNAPBACK}][/a][/div]
It runs a bit deeper than OESF, I'm afraid.
It takes a LOT less energy to whine, than to actually accomplish anything in code-
for the most part. The reason people whine, instead of stfu, is that there's some magical belief that with language we can make things happen that we can't actually do ourselves.
Strangely, most of us can find evidence from personal experience to support this kind of thinking, even if it tends not to hold up very well in the real world.
Koen: people who whine, tend to think they are doing *something* (whining is a thing) but they have the mistaken impression that others who are busy coding/living/breathing/having a life/debugging/etc but not whining, are actually in fact doing nothing.
Koen/hrw/pgas/sash/laze/zotdd: thank you all for doing *something*
-
Could someone do me a big favor and explain the differences between pxafb overlay support and the functionality of the BVDD module?
Basically, with the OZ PXAFB overlay support, will I get the same end result from the BVDD module, once implemented?
-
Could someone do me a big favor and explain the differences between pxafb overlay support and the functionality of the BVDD module?
Basically, with the OZ PXAFB overlay support, will I get the same end result from the BVDD module, once implemented?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142972\"][{POST_SNAPBACK}][/a][/div]
bvdd is some linea invention that deserves to die a slow, horrible death, kernel 2.6 will never support it. The overlay support will make use of the pxa270 framebuffer features, like YUV->RGB conversion and hardware cursor. The OZ kernel does miss support for putting parts of the framebuffer in SRAM, but that doesn't stop you from using the overlays, it's just a bit slower. If you post a link to your sources hrw and I can make a bitbake recipe for it in a few seconds so everyone is able to build it, not only for arm, bit other architectures as well.
-
Ah! I see.
Since I'm writing ZPSX (a PSX emulator for the Zaurus), I don't really have a use for YUV overlays. What I noticed in 2.4 kernels with BVDD was the large increase in the speed of blits from the usage of SRAM.
See, math aside, a 5ms delay in a blit to the screen can make a difference of 8 or so FPS. It just averages out that way. That SRAM support is what lowered the blits from 6-8ms to 1-3ms.
Keep in mind I use the BVDD "enhanced" SDL lib for the ZPSX builds. But I could go without SDL too.
So, while overlays will be great for MPlayer, it doesn't look like it will help me much. Would I be able to get access to the SRAM within reason, or would I have to comile a kernel module etc...?
Bitbake sounds quite cool! ZPSX is an ARM specific build of our (currently) closed-source psx4all project. Since psx4all supports a highly portable version, and an ARM as well as MIPS32 specific version, Bitbake could help a lot. If it does open up soon, you'll be the first to know.
-
To make sure my post is understood the way I want: it is not danboid I ignore, but koen.
Koen, why are you still here? Is it for whinning about users and ignorance?
Why do you release your work? Keep it private, don't bother answering questions.
IMHO you've done more harm than good here. Hopefully you might grow up one day and quit this stupid attitude of yours.
I do not look forward to your answers.
-
Ha!
I've been crying out for overlay support all this time and it turns out its not what I want at all!
I'm glad to see zodttd is interested in this as he's the kinda guy with the skills to sort this out methinks
SRAM support is the new King!
Long may I nag!
-
So, while overlays will be great for MPlayer, it doesn't look like it will help me much. Would I be able to get access to the SRAM within reason, or would I have to comile a kernel module etc...?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142977\"][{POST_SNAPBACK}][/a][/div]
If I read the comments in the patch right, the pxafb code should automagically use the SRAM if it's enabled in the kernel. I haven't been able to test it since the overlay and sram patches don't apply to the 2.6 kernels for my motorola a780
-
That's great news!
I can almost smell accelerated mplayer and zpsx for cxxxx owners!!!
-
Why do you release your work? Keep it private, don't bother answering questions.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142978\"][{POST_SNAPBACK}][/a][/div]
I think it's a moral obligation to share knowledge and new technologies so anyone can benefit from them.
-
from http://www.psx4all.net/ (http://www.psx4all.net/) :
"PSX4all Public Beta 4 released for GP2X and Zaurus -(Playstation Emulator)
<snip>
Note: The Sharp Zaurus build has only been tested to work on pdaXrom. Cacko, OpenZaurus, and 2.6 Kernel distro builds are being worked on."
Hope to see it soon! Thanks and cheers to zodttd and the psx4all team!
Also many thanks to Hrw, Rpurdie and everyone else who worked on bringing PXA video acceleration to OpenZaurus.
-
Yeah, I can't wait to try out the new zpsx, but I'm not going to be installing pdaX especially.
Could any of the OZ devs give us the lowdown on SRAM support. Is it being worked on or does nobody know how it should be implemented?
I'd much rather see the new zpsx under OZ w/ SRAM support