GP2X [rant] Why Isn't Gph Embracing The Dev Community?

[GeminiDomino]

Not to worry though, as no doubt someone will "send the boys round" if they keep this up

​

Step 1: Get some halfway credible gamer-blog to do up a story on the issue.
Step 2: Post said story to Slashdot.
Step 3: Get the hell out of the way!

Problem will solve itself quickly, youbetcha.

 

[nubie]

The gp2x is basically a MagicEyes's MMSP2 chipset (plus 64MB sdram), right?

The rest are just peripherals so... MMSP2 is common part, sdram of course too. It should not be too costly or difficult to build another machine based on MMSP2. I'd like to have a very small desktop computer running Linux with TV-out, VGA out, audio out and usb host/slave connectivity. With 128 (or even 256) MB of ram it should be enough for my typical tasks like text editing using Vim, some programing with Python/C, some games (I'm already tired of 3d being pushed everywhere) and media playing.

With 15 lcd monitor it could be even smaller than a notebook and... it could be even built in a monitor itself!

​

I had this thought to make a 6"-8" (maybe up to 10"-15" like you are thinking) screen of maybe 640x480 resolution and put in USB host with a hub and the whole thing and run off of 4 AA batteries etc., but using the original board from GP2X to save on manufacturing costs.

My idea is handheld, but not *really* portable.

Back on(off) topic:

wheeeeee!! I am in a flame war. . . Bad GIR, get away from that keyboard. . NOOOOWWW!!

Honestly, it is very strange in this day and age to be having problems communicating, although their culture is very different from ours.

I notice that GPH has good motives in that they actually recalled units with hardware faults (possibly only in Korea though), but it appears they don't have the resources to fix the firmware quickly.

I think what we really are bothered by is the lack of information, first comes uncertainty, then doubt, then fear, and sometimes anger. (I am naming this phenomenon UDFA, and I would like to honor GPH for the first ever Korean national(international) occurance of ARM related UDFA. )

 

[RiX0R]

I think what we really are bothered by is the lack of information, first comes uncertainty, then doubt, then fear, and sometimes anger. (I am naming this phenomenon UDFA

​

You might very well be Yoda

 

[Radek]

The gp2x is basically a MagicEyes's MMSP2 chipset (plus 64MB sdram), right?

The rest are just peripherals so... MMSP2 is common part, sdram of course too. It should not be too costly or difficult to build another machine based on MMSP2. I'd like to have a very small desktop computer running Linux with TV-out, VGA out, audio out and usb host/slave connectivity. With 128 (or even 256) MB of ram it should be enough for my typical tasks like text editing using Vim, some programing with Python/C, some games (I'm already tired of 3d being pushed everywhere) and media playing.

With 15 lcd monitor it could be even smaller than a notebook and... it could be even built in a monitor itself!

​

I had this thought to make a 6"-8" (maybe up to 10"-15" like you are thinking) screen of maybe 640x480 resolution and put in USB host with a hub and the whole thing and run off of 4 AA batteries etc., but using the original board from GP2X to save on manufacturing costs.

My idea is handheld, but not *really* portable.

I'd be very nice if GPH (or other company) would sell just MMSP2 mainboards. Only chipset plus ram and connectors for peripherals. Could be more power efficient, smaller than the nanoATX via based solutions. Arm based processors are really much better for such devices than any derivate of x86 or whatever.

The future SoCs should have over 500mips of general processing power plus FPU, decent 3d capabilities, built in dedicated wavetable synthesiser, etc... The magiceyes's VRender3D SoC is already quite close to such thing (except for a cpu).

I see no a reason why personal computers should be big noisy boxes anymore. Looking here it's clear that even a x86 made big progress toward concept of small yet powerfull computing.

Isn't it funny that people are buying transistor monsters like latest PIV incarnations for tasks like video encoding? A dedicated coprocessor would give superior perfomance at fraction of die space and cost...
(and this is why the gp2x can play even xvid encoded movies - has a coproc for it)

Back on(off) topic

Yep.

wheeeeee!! I am in a flame war. . . Bad GIR, get away from that keyboard. . NOOOOWWW!!

Honestly, it is very strange in this day and age to be having problems communicating, although their culture is very different from ours.

I notice that GPH has good motives in that they actually recalled units with hardware faults (possibly only in Korea though), but it appears they don't have the resources to fix the firmware quickly.

I think what we really are bothered by is the lack of information, first comes uncertainty, then doubt, then fear, and sometimes anger. (I am naming this phenomenon UDFA, and I would like to honor GPH for the first ever Korean national(international) occurance of ARM related UDFA. )

​

Different people live at different speeds. We are "fast" here, we want a things to be changing at "our" pace. I have my gp2x for less than three weeks and already had to unbrick it, open it, learn about many new things...

This isn't so for others.

Not defending (at least not much) GPH but look at Sony or Nintendo. They have much more money and are they really moving any faster? They always had delays, hardware issues, software issues and all other crap.

This is unfortunate but it's typical that companies are slow.

 

[evolutional]

If dignsys don't comply and GPH were to drop them as a sub-contractor then GPH could demand a source release and then turn it over to the community for completion... It would be messy, but GPH would by no means be left in the dark.

If I was running a company I'd rather not cut off my kernel development team and leave it open to the community to code up. What happens if the community decide the GP2X sucks and then GPH are left with nothing but a half finished kernel. More than likely, DignSys are contracted as being the only kernel developers for the system (perhaps obligated for a year or for a fixed number of releases) so GPH have no way out of the contract.

Another concern I have is the issue of bricking the GP2X, there'd be nothing worse than people trying out a community project that isn't complete and bricking their GP2X - for the kernel hackers this is no concern, they can probably restore, but for 'mainstream' users this would be a very big deal and would shake their faith in the system as a whole.

That said, I do love the idea of the community taking the system forward, just as long as we have ways of easily restoring 'broken' systems caused by bad firmware updates.

 

[evening2005]

If dignsys don't comply and GPH were to drop them as a sub-contractor then GPH could demand a source release and then turn it over to the community for completion... It would be messy, but GPH would by no means be left in the dark.

If I was running a company I'd rather not cut off my kernel development team and leave it open to the community to code up. What happens if the community decide the GP2X sucks and then GPH are left with nothing but a half finished kernel. More than likely, DignSys are contracted as being the only kernel developers for the system (perhaps obligated for a year or for a fixed number of releases) so GPH have no way out of the contract.

It's hard to speculate about the relationship between GPH and DignSys without knowing the details of the contract, but at least one of the parties must release the source code each time the release a new version of the firmware. There is no doubt at all about that.

Another concern I have is the issue of bricking the GP2X, there'd be nothing worse than people trying out a community project that isn't complete and bricking their GP2X - for the kernel hackers this is no concern, they can probably restore, but for 'mainstream' users this would be a very big deal and would shake their faith in the system as a whole.

Well, people are bricking their units now when they try to upgrade the firmware - I don't think that would be more likely with a community-developed release.

That said, I do love the idea of the community taking the system forward, just as long as we have ways of easily restoring 'broken' systems caused by bad firmware updates.

I think that (more ways to unbrick GP2Xs) would be more likely if there was a more open approach from GPH. And in any case, they (or DignSys) have no choice in the matter. They must release the source code. When they do so, if a community developed firmware is released, consumers will be able to either choose the "official" one, with whatever protection that affords through the warranty, or they can go with the community one, with whatever attendant risks. The key thing is to give people choices.

​

 

[MiniMoose]

I suspect that opening up the source using CVS might make matters worse
if the flood of suggested code changes required more time for GPH staff to
review and implement than to do their own work.

​

GPH wouldn't slow down if they adopted the same management structure that Linus uses for the Linux kernel source code. Active developers like r1yeh, squidge, and rob could vet the patches and find the ones that should get into the next release, clean them up and apply them to the main branch.

Then GPH (read Diginsys) would need to make builds of the main branch, do Q/A, and then create a label in CVS and release a .zip file on the site.

All of us developers could be tracking the main branch all this time and helping them work out the bugs in the new features.

What is most frustrating to me is that they have the perfect business model for embracing the open source community and they aren't fully leveraging that. If I were running GPH, I would be relying on the hardware sales and a cut of commercial game sales to keep the business going while leveraging all of the work of the open source community to ease the cost of improving the firmware and adding new features. The open source community is be a key asset that lowers the company's overhead and provides free marketing.

 

[MiniMoose]

That said, I do love the idea of the community taking the system forward, just as long as we have ways of easily restoring 'broken' systems caused by bad firmware updates.

​

There are very simple ways to engineer a system so that it is "unbrickable". Being able to boot from the SD is the most obvious one that comes to mind. You could also leverage uboot's ability to have side-by-side images of two kernels, the old one and the new one. Using a key combo you can select between them at boot, thus allowing you to test a new kernel while still having the old working kernel to fall back on.

 

[chris_r]

GPH wouldn't slow down if they adopted the same management structure that Linus uses for the Linux kernel source code. Active developers like r1yeh, squidge, and rob could vet the patches and find the ones that should get into the next release, clean them up and apply them to the main branch.

No. Gph should be managing the main branch themselves but they should be reviewing other peoples code changes.

You seem to forget that this is not the only gp community, so handing over the task of code maintainance to a few developers from our community when there are many other communities in different countries with potentially more experienced devs wouldnt be wise.

 

[Hanz™]

GPH wouldn't slow down if they adopted the same management structure that Linus uses for the Linux kernel source code. Active developers like r1yeh, squidge, and rob could vet the patches and find the ones that should get into the next release, clean them up and apply them to the main branch.

No. Gph should be managing the main branch themselves but they should be reviewing other peoples code changes.

You seem to forget that this is not the only gp community, so handing over the task of code maintainance to a few developers from our community when there are many other communities in different countries with potentially more experienced devs wouldnt be wise.

​

I think most of the experienced devs are actually from here to be honest.

 

[chris_r]

Either way maintaining the main branch of the kernel should be gph's job not the devs

 

[BradN]

It doesn't really matter who does it, as long as it gets done... but it seems there's a bit of a disconnect between GPH and the developers who will actually write the software - it's visible in some of the design choices (there's a kernel module loaded the whole time to support the video player with the 2nd CPU, but it uses some upper memory space even when it's not being used? the video player should load the module on demand, or better yet, GPH should have made a real kernel interface to the 2nd cpu, to give access to interprocessor interrupts and things like that, etc)

 

[bjimba]

GeminiDomino had the right idea. This issue will not be resolved without some publicity outside the GP2X developers' niche.

To that end, I've tried to calmly sum up the issues involved on my blog. Here's the article. Take a look, see if I've got things covered. Then, if you want to spread the word, link to the post. I've already suggested the link to slashdot.org and boingboing.net, and added it to del.icio.us.

The more links, the better. Blog about the issue yourself. Get the word out. Don't villify GPH or Dignsys, but remember this is not a favor we are asking of them. This is a requirement of using the Linux source code in the first place.

 

[MiniMoose]

Either way maintaining the main branch of the kernel should be gph's job not the devs

​

Just like Linux maintaining the main branch of the Linux kernel. Linus uses other developers who have expertise in areas of the Linux kernel source to sort through all of the submitted patches to find the ones that fit into the direction Linus wants to take the kernel. It's a distributed managment system that focusses the community effort and prevents the full burden of communication from falling on any one person.

 

[MiniMoose]

GeminiDomino had the right idea. This issue will not be resolved without some publicity outside the GP2X developers' niche.

To that end, I've tried to calmly sum up the issues involved on my blog. Here's the article. Take a look, see if I've got things covered. Then, if you want to spread the word, link to the post. I've already suggested the link to slashdot.org and boingboing.net, and added it to del.icio.us.

The more links, the better. Blog about the issue yourself. Get the word out. Don't villify GPH or Dignsys, but remember this is not a favor we are asking of them. This is a requirement of using the Linux source code in the first place.

​

I just posted it to Digg.com in the Linux/Unix category under the title: "Linux-based Portable Gaming Device Manufacturers Not Following GPL". Jump on over and digg the story by going into the "Digg for stories" section so that it gets promoted to the front page.

 

[bjimba]

Well, we'll now see if publicity of the issue helps. We got a SlashDot link, and my blog is currently being SlashDotted...

 

[GeminiDomino]

*steeples his fingers*
Excellent... my plan is in motion.

 

[Ravnos]

Soon the dominoes will fall like a house of cards. Checkmate.

 

[furikuri]

*steeples his fingers*
Excellent... my plan is in motion.

​

I just hope your plan doesn't backfire and take out GPH in the process.

 

[GeminiDomino]

*steeples his fingers*
Excellent... my plan is in motion.

​

I just hope your plan doesn't backfire and take out GPH in the process.

​

There is little chance of that happening. Even if the FSF (copyright owner for linux) does step up to the plate, they tend to go for compliance rather than damages. The only way GPH goes down is if they continue to refuse, thus putting themselves firmly on the wrong side of the law. If so, they'd be very stupid and it would be their own doing.