To pour some water on the coals: for the _very little_ I know about MBX, so don't take this as absolute truth, there are issues in the way the driver would be structured. While the SGX allows for a mostly userspace based driver, which would simplify IPR and licensing issues, the MBX would need to have all the beef in kernelspace. So that's one more reason why there is little to no interest from Nokia side about it. We are not really so fond of tainting the kernels we ship. About rewiting, there is a small problem: those who would do it have to sign ndas lasting decades.
Anyway, having seen a few demos running on the MBX, let me tell you that they are not too impressive: what i saw was running on a qvga screen and still it wasn't particularly fast. I doubt one would get much performance on a tablet screen withouth having to use pixel doubling and similar tricks.
You are saying that nokia will happily provide closed source modules for practically every part of the system is afraid of "tainting" the kernel?
Forgive me for feeling a little bit dubious about this.
The performance may not be that great, but by taking even some of the workload off the cpu would allow us to be able to run better newer games and do better newer things with our devices.
As for resolution, it doesnt seem to effect the iphone to have a lower resolution, and hundreds of devices work perfectly well at the lower resolutions. Coupled with the fact automatic scaling from arbitary resolutions upto fullscreen size is built into the LCD controller makes that argument a little weak.
I don't know where you stand within Nokia and I don't mean to shoot the messenger so to speak, but I find none of the reasoning given by you or others (apart from money aspect) to be realistic.
The pvr is technically capable and I would really like to use it.
The performance may not be that great, but by taking even some of the workload off the cpu would allow us to be able to run better newer games and do better newer things with our devices.
Of course that might be true up to a certain point.
As for resolution, it doesnt seem to effect the iphone to have a lower resolution, and hundreds of devices work perfectly well at the lower resolutions. Coupled with the fact automatic scaling from arbitary resolutions upto fullscreen size is built into the LCD controller makes that argument a little weak.
I don't have an iphone and after playing with one, i am not interested in it at all because of the low resolution - amongst other things. So the fact that others are willing to put up with it doesn't really say much.
I don't know where you stand within Nokia and I don't mean to shoot the messenger so to speak, but I find none of the reasoning given by you or others (apart from money aspect) to be realistic.
Certainly i don't sit in the control room :-)
I merely say what's the state of things, compatibly with my nda.
But no misinformation, if i cannot say something, i just shut up.
So, believe it or not, what i said is the plain truth, to the best of my understanding.
The pvr is technically capable and I would really like to use it.
Then you can try other approaches: ask the manufacturer to open up the specs (and good luck with that), try some reverse engineering of an existing binary driver, or write a wrapper for the same existing binary driver.
Igor,
Firstly I would like to apologise for my grumpy post - I dont usually post so early and you got my heckles up.
I am very pleased to hear you and others are attempting to open up as much as possible - it is genuinely good.
I think you understand the outsiders perspective however which is sheer frustration.
Myself and others are trying everything we can to get this device to perform as well as it can and see the pvr as a bit of a roadblock to that.
We have already been told there *are* linux drivers around inside nokia and we are doing everything possible to improve the situation ourselves.
I would personally not like to fully reverse engineer anything, but think a wrapper around an existing driver is a possible way to sidestep the issue.
Whether or not that will be required in a couple of months is another matter.
There's also a user-space library which communicates with the kernel driver, so even if the kernel driver can be reverse engineered, that library will also need to be.
I really hope you will be successful with that hack. The n8x0 has got so much potential to be useful for years to come. And every step to unlock unused features will help the devices to survive.
I remember Quake 3 running on an Axim x50v/x51v with a PowerVR MBX-lite GPU. It was quite impressive. If the Axim had a better processor with a FPU like the Omap and more memory(it had only 64MB) it would have been awesome. The Axim is still alive, because some hackers got newer OS-versions to run on the device after Dell dropped support.
To see the n8x0 get sorted out one day before at least trying to release its full power would be a shame.
Good luck to everyone trying to do what has to be done!
Re. all this talk about drivers left and right - using iPhone, N95 or <insert device>'s driver. These are all binary drivers. What would be useful for a Linux/ARM driver would be source code for the abovementioned drivers, as at least that could in principle be used to deduce enough of the workings of the chipset to write a proper Linux driver.
However, with binary drivers you would have to reverse engineer from the binary code, which is simply utter pain for the code of almost any modern CPU. (I mean, it can be done, but there's so many more fun things to do in life..)
The other way of using a binary driver would be to use a "wrapper", but to do that you need a well-defined ABI that you _know_ the driver is using. It's been done before, e.g. with the 'ndiswrapper' project for x86 Linux. It's a wrapper which can load Windows wireless network drivers written for the Windows 'NDIS' ABI. It works very well, however it's a project that's taken _years_ to get to today's very stable level, and it's for a driver ABI that is not only well-defined, Windows drivers are also rigidly tested for compliance. Also note that the NDIS specification is much easier to wrap than many other driver specs, because it defines a lot of operating _calls_ that the drivers must use instead of accessing data etc. directly. This makes it much easier to write a wrapper - you just write your version of the functions that the driver needs to call.
There's a reason there are not that many binary driver wrappers out there.. it _sounds_ like the easy way, but every other solution is almost always less work.
TA,
You are right thats its taken a long time to get the ndis drivers up to scratch, but is that more resistance against the approach than anything. Now that linux x86 has the functionality it benefits everyone.
if it comes down to working out the ABI for a Symbian binary vs working out the chipspec for the entire PVR I know which I am going to choose.
The symbian driver talks in strictly defined functions and seems the logical step backwards from the chip interface.
We gain the benefits of the library and let the binary driver deal with the nitty gritty.
