Current Status Of Gnu/gpl Infringement?


Last edited by a moderator:
evol said:
yes i looked at that but im really just fishing for clues that points me in the direction of what chip they are using, like in the vrender0 they have other chips who handle 2d and so forth i bet they use some cheap eisc chip like
Click to expand...
Well, they definitely don't use the same chip for hw mpeg decoding in the mmsp that they use in the vrender3d, as I have the documentation for the later, and the mmsp hw is nothing like it.
 
Last edited by a moderator:
sehs33 said:
Convincing, but can't anyone reverse engineer it/part of it? am just asking because I know very well how easy it is to reverse engineer software written in modern languages like Java\.Net\ActionScript etc...
What would be needed for it to be reverse engineered? or is that completly impossible?
And what about GPH giving MagicEye a good offer for part of the specifications? the sales of the GP2X will increase well if it had a fully playable PSX emulator/other applications that developers can come up with using these info (although I doubt GPH would ever consider this, they didn't even license wma\wmv as they were planning earlier).
Click to expand...
Thats sounds great! So brilliant!!

Why dont you do it? :p
 
Last edited by a moderator:
There's a vrender in the MMSP2. It's a 2D version of the vrender3d, which I believe is indeed called the vrender0. I don't know if it's a rebranded chip or if MagicEyes owns the chipset (doubt it).

EDIT: As for the idea above, I also doubt GPH can handle any sort of payment more or less for something considered worth money to MES. If GPH cared about developers, they would of gone about the GP2X completely differently, from the hardware and the inspiration behind it. I don't think they understood the market they were feeding with the GP2X, only that they wanted to build a new gadget and could. It seems to be a popular trend in SouthKorea.
 
Squidge said:
fw3.0 still uses and oldish kernel - not much as changed there.

incomplete mplayer sources GPH have no power over. Magiceye's themselves refuse to publish both source code and documentation concerning hardware mpeg decoding. However, since mplayer is compilable without those sources it's not a gpl violation.

uboot sources have been released, and people have built there own uboots, so I assume they are complete.
Click to expand...
Waait. mplkayer _can_ be compiled sure, but not _as is_. The magic eyes part isn't in a shared lib and dialed up on demand, its part of the binary. (Unless I'm wrong on that point.) As such, they _are_ in disagreement with the GPL.

If its a separate shared lib thats conditionally sucked in, then they would be compliant on that count.

jeff
 
Last edited by a moderator:
I would think about the decoder module as a hw driver that mplayer needs to access to output anything, I don't think that conflicts with gpl?
Else closed source vga drivers would as well, wouldn't they?
 
If you have GPL code, and link in non-GPL code, it is in violation. ie: If someone cannot have everythign availabnle for recompilation of what they have, it is voilating.

If you can recompile "minus some features', thats not compliant. ie: People are losing features.

The GPL's entire purpose is to ensure that when you modify something, you must return it to the pool; if they're static linking in their wokr, but not releasing it, they're breaking the terms.

(I'm just being pedantic, but thats what this post is about :)

jeff
 
MMSP2 Decoder program(in 940T) is not static/dynamic linking with kernel/mplayer, only communication via memory/register/interrupt.
 
Jeff, you can compile mplayer and get exactly the same functions as the original mplayer, as the magiceyes part is distributed as a binary module to upload to >32mb so the 940 can see it. I don't see how this can be a GPL violation as the binary module is completely seperate from mplayer and is loaded via opening /dev/dualcpu.
 
@squidge if i understand you correctly dualcpu.o reserves
0x03000000~0x03FFFFFF (simplyfied)

it seems peculiar that the vrender0 Eisc Cpu uses that chunk for

GraphicEngineRegisters+TexturebufferMemory

can you tell me anything else about the mem layout for the gp2x that seems "strange" or noteworthy (i really would like to figure this out so bare with me plz, i know i can be uber n00bish)
 
None of it really feels "strange" as such, but what I can tell you is that Magiceye's "ported" WinCE to the MMSP2 a long time before Linux, and as such the first 32MB of RAM was reserved for the OS, and the second lot of 32MB was dedicated to the 940 (code+data).

The memory areas you state are the default memory areas. However, they can be changed - the reserved area can be dynamically allocated. You can also use pre-allocated or reserved 2D YUV sets. Also you can make your own 2D YUVallocator (940/MPEG processes YUV rather than RGB).

The only thing that is fixed is where the firmware is stored, and that is simply because of the address it was compiled for. Magiceye's can release a binary on request that will work from other locations (but obviously they will not do that for nothing...)
 
DJWillis said:
Just to chip in on this and confirm what others have said.

At the current moment GPH are in full compliance with the letter of the GPL on there current release, all GPL code used is available from there SVN server and indeed builds, including U-Boot and mplayer (that said they can be a real bitch to build but that is not the same as ‘wont build’).

The issues people mention around the binary MMSP2 H/W module or the GPH menu apps and such are a non issue from the GPL point of view as they do not feature (as far as we know) any GPL infringements or (L)GPL code that is linked in a way that is not compatible with the licences.

It is fair to say GPH and its partners/suppliers could be well advised to take a more open and community focused approach with source code and specifications but there is no compelling or legal reason for them to do so.
Click to expand...
If this is the case (which is great), it might be worth updating the wikipedia page, which makes the situation sound a lot worse. Missing firmware, missing uboot, violation in mplayer.

Wikipedia said:
Copyright violations
Click to expand...
The GP2X firmware uses a significant amount of GNU GPL code, including MPlayer for its media functions and the Linux kernel for its OS. The GPL requires for the release of the source code to users of the binary application (i.e. GP2X users); however, the source code was not released when the GP2X was released to consumers.[7]

* February 18, 2006 - Kernel source for Firmware 1.4.0 released.
* July 6, 2006 - Modified MPlayer source code released, however without significant bits to use the hardware Mpeg-4 decoder, and since that was statically linked into the MPlayer binary, currently it has been moved out to a precompiled closed source kernel module, a GPL violation in itself.
* The kernel source for Firmware 2.0 has also been released, however the i2c code had been removed, so a copyright violation is still present.
* Much of the "U-Boot" bootloader code is missing from what they have released.[citation needed]
 
Last edited by a moderator:
I've tried to keep it up to date, but there are some very determined people out there who insist there are loads of problems. Recently somebody have been replacing the entire page with "GP2X SUCKS!!!!!".
 
You must log in or register to reply here.

Similar threads

J
Current State Of Video Playback Support?
Replies
16
Views
2K
mylan
M
D
Gp2x Gpl Faq
2
Replies
36
Views
6K
DijiTao
D
G
Direct Answers From Gamepark About Gpl Etc...
Replies
19
Views
4K
gHeTTo cHiLd
G
djcpe
Current status of the "que" lists
Replies
1
Views
1K
moxie
moxie
B
Current Status Of Emulators
Replies
14
Views
5K
darklegion
D
Back
Top