RE: len0x: apps settings.c,1.310,1.311
On Thu, 3 Nov 2005, Anton Oleynikov wrote: http://forums.rockbox.org/index.php?topic=1712.0 That is about three *users* supporting this move. just usability improvement... Usability if you use and like the feature yes, it certainly is NOT if you don't use it and aren't used to it. (Like for me.) IMHO, we must not run ahead and patch things in Rockbox just because there's a bunch of users in a forum somewhere screaming for it. Rockbox is made and designed by developers. *We* should discuss and decide on what to do. And one of the main reasons we started this *dev list is so that we can bring back the good old mailing list developer discussions. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: len0x: apps settings.c,1.310,1.311
On Fri, 4 Nov 2005, Anton Oleynikov wrote: I see that you're not working in the software industry. You see that? Wow. How perceptive of you. But if we start discussing things like: what should be default behaviour, how should we phrase it, what icon should we use etc. - then I think we should leave it to the end user because we're doing it for him... Then we simply disagree on this. Besides, knowing what users want is not very easy and I just cannot imagine a system where we decide on things based on some kind of guess what users want. No. We are developers, we discuss things, we decide things. We are users too. In the end - we're having a dicussion now and its not really a big deal to rollback the change (and I will have no problem with that). But there has to be a good reason for that I'm not saying everything must be debated and argued to death before something is committed. I was just so very surprised to see this commit as we've had this feature for AGES like this. Then you have CVS commit access only a few days and then you commit this. This alerted me and thus we have this conversation. But I just wanted to know if we can do things that not everyone agrees with. The total number of developers is quite high, so always there bound to be someone who doesn't agree. What do we do then? One way could be to attempt to discuss the matter first. To figure out the background and to understand the whole picture. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: amiconn: apps settings.c,1.319,1.320
On Mon, 7 Nov 2005, Anton Oleynikov wrote: The ONLY reference to global_settings.next_folder is in the apps/playlist.c which is not used by Archos. apps/playlist.c is used by all players that run Rockbox, including the Archos models. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: longer Recent CVS activity ?
On Mon, 14 Nov 2005, Frederic Devernay wrote: would it be possible to have a page on the web site with a longer version of the recent CVS activity, or an archive of the CVS commits? http://www.rockbox.org/since25.html - updated daily. [My rockbox/iriver sometimes doesn't want to shut down, I have a 1-week build, and I wonder if this issue has been fixed] Nope, we are several people who has been hit by the same problem... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: bundled WPSes = themes?
On Wed, 16 Nov 2005, Ronald Teune wrote: How about automatically loading wpsfilename.cfg at opening the .wps file? Then there's no need for extra menus and stuff, and it would be a simple change. It might have some side-effects like users seeing weird stuff because they don't know their settings have changed, but that would be the same when using themes. If I understand correctly, what you want now is 1) browse cfg files, 2) browse wps files, 3) browse themes. This sounds a bit doubled up. Correct me if I'm wrong. :-) The reason is that I still want to allow the user to pick individual pieces, like selecting a WPS without changing font etc. So, picking a WPS or a font only changes that particular thing. For maximum flexibility. Only a theme .cfg would then set more than one thing at once. I would rather just remove the browse wps choice from the menu, but that's probably not as fun for those who add their own WPS to the dir and want to be able to pick it from the menu... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
x11 sim with colors
Hey I could really use some assistance to make the X11 sim to support colors. We have several targets with color LCDs now, and I hope we'll see even more of them appearing in the future. Having the x11 sim non-functional for these targets will hamper development. I'm personally swamped with work and my attempts at a quick fix to solve this was not successful. I don't think I'll be able to add this anytime soon. A general X11-programming advice: there are lots of examples of X11 programming in the xscreensaver's suite of hacks that can serve as inspiration. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: sound scaling patch
On Tue, 29 Nov 2005, Tony Lenox wrote: I've made a setting patch out of the original sound scaling patch (to allow raise volume up to 100% by reducing bass instead of limiting now for iRiver) here: http://forums.rockbox.org/index.php?topic=956.150 If so, what are the option and its alternatives called? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: sound scaling patch
On Tue, 29 Nov 2005, Thom Johansen wrote: If we are to add another setting, I'd also like an option that doesn't limit anything at all, but just let's the audio potentially clip. And the forth: lower the value I'm *not* currently changing so that you can drive up the bass to max and thus have the volume lowered, but then when you switch to the volumne and raise that to the max you get the bass lowered... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Makefile cleanup
On Sun, 4 Dec 2005, Magnus Holmgren wrote: * Several codec makefiles contain a rule like this: $(OBJDIR)/codec/%.o: $(APPSDIR)/codecs/codec/%.c But it doesn't match, so the build rule in make.inc is used instead. Oops. I guess that mistake is mine! Thus, all the extra stuff in the $(CC) command of the rule isn't needed and can be removed. It also means that the only thing the rule really adds is allowing for a different echo line. It also means that at least some codecs (e.g., liba52) are built using -O rather than the intended -O2. So, what to do? Correct the rules and remove the uneccessary stuff, or remove the rules completely? Personally I think we can go with the make.inc rules as long as they work, since it makes the makefiles smaller and it makes less places the compiler is invoked. * codecs/Makefile creates a dependency file, but it isn't used, afaict. Should it be used or removed completely? Without checking the makefiles, I would say that we should make use of the depfile so that proper dependencies are used/dealt with. * codecs/Makefile define OUTPUT when invoking the codec makefiles. Many of the codec makefiles define OUTPUT too (and to the same value). Clearly, two definitions is one too many, but which should be removed? I'd say the ones in the codec makefiles. I'd say so too. I believe they are mere leftovers from one of my latest cleanups and I probably just didn't clean up everything I should've. * I've found one thing that makes make clean slow on Cygwin: dependency generation. Adding a ifneq ($(MAKECMDGOALS),clean) around each depenecy file include speeds things up. Is it okay if I add this? (After all, there's no point in updating a dependency file that is about to be deleted anyway.) I always knew it did that, but this solution never occurred to me. I'm fine with adding it! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Anton Oleynikov wrote: The whole point of me doing first patch was that second option. It was extensively discussed in the forum and now that seem to be eliminated, right? In the forum perhaps, but not a lot here. How come? Jens explained it pretty well in his mail, IMHO. And no matter what, it is always considered fine to improve whatever we did before. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Anton Oleynikov wrote: And no matter what, it is always considered fine to improve whatever we did before. Improve - yes, but completely remove what I've just done after not even speak up when asked - its another thing :) But he mailed here now and we're debating it atm. He hasn't committed anything yet. Feel free to argue for your viewpoint. There's no point in debating why the debate was lacking or made differently before. AFAICS, we're pretty united supporting his approach. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Simplified and uniform volume handling - asking for opinions
On Tue, 6 Dec 2005, Michael E. DiFebbo wrote: I also believe that having a prevent clipping function similar to what Anton developed is beneficial to Rockbox, particularly with respect to making it more accessible to less sophisticated users. All the discussions that have been held on this topic, that I've read, have more or less stated that people have not understood or liked the previous concept used by Rockbox, with some stating that they'd prefer the original iriver fw method. The approach Jens suggested has not been widely discussed or tested. we also retain at least the portion of Anton's prevent clipping function that scales back bass boost to prevent clipping. Yes, we might have to. But we've had Jens' system for the Archos models for years without needing a prevent clipping option so I think it is a fair idea to go without that option to start with. People are in fact used to stereo equipments etc that clip when you drive everything to too high levels. Also, it is not 100% clear exactly how the scale back bass should work. Many of you have argued, in various ways, that Anton's approach is less desirable then Jens' approach because Anton's approach leads to undesirable option bloat. That's only one reason. There are more reasons, including: there are too much magic happenining under the hood and that the options are very hard to understand/differentiate. The premise underlying these arguments is that Rockbox already has too many options and that adding more makes it unapproachable to new users or overly complex.* I disagree with this premise for several reasons. The ground rule, that many of us core devs are sticking to, is that adding options is a necessary evil that you avoid as far as possible. In a few years from now, you too will realize why this is a winning concept. First, I think that this issue goes directly to the heart of what an audio jukebox is about: the users' experience in listening to music. It is abundantly clear that the handing of volume and clipping is important to the Rockbox user base. I disagree. It is not clear. It is clear that the previous approach surprised a lot of previous iriver-firmware users. It's also clear that this issue is critical to the developers; Yes, but to me at least more in the sense that we want to keep Rockbox simple, understandable and without bloat. I've never personally experienced the cap limit, be it the original or Rockbox's, not before not now. I don't understand why there is such reluctance to implement a configurable option with respect to clipping prevention. Because if we can work out a system without an added option, that is an even better approach. There are many other Rockbox functions that have more numerous and more complex options. That is not a good argument. Just because we have been sloppy or done mistakes in the past is not a good reason for us to do them again. The peak meter alone, for example, has SIX different options. The LCD has NINE different options. The crossfade function has six different options I would say that each of these are example of option-bloats that we should address and cut down on. But it isn't easy to remove or cut down what has already gone into Rockbox as there's a wild user base that likes every part you'd try to change. It is _a lot_ easier to break and address things _before_ they go in in the first place. And in fact, if we had not been practising the More Options Are Evil philosophy we'd have a *bazillion* more options than we have today. It doesn't seem unreasonable for users to have at least ONE option (ON or OFF) with respect to clipping prevention. ... nope, and there is no major resistance against such an option. Just a mild Do we really need it? And a How exactly would such an option work? And a Such an option *really* should be user-visible when in effect and how would that work when the apps don't have detailed info about the DAC? etc If there really is a belief that Rockbox has too many options I think most people (both devs and users) would say so. Advanced settings I'm against advanced or expert options. We've had this argument many times and I firmly believe: 1) we'd get lots of arguements which options that are advanced 2) all users would still use the advanced options I do NOT think that bass limiting should be implemented because that is the way that iriver does it. I agree. Rockbox is a lot more than an iriver firmware and we do not mimic iriver's behaviour. We should do what we consider is The Right Thing in any given situation. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: new wps-file-loader
On Tue, 6 Dec 2005, Stephan Wezel wrote: The loading of a wps-file is done line-by-line. Does it still require some special formatting (on their own line or similar) of certain tags? I seem to recall that it at leased used to do that, or I am just staying up too late now again? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: MPeye HTS-150
On Wed, 14 Dec 2005, Tim Schmidt wrote: The latest firmware is available from MPeye at: http://mpeye.co.kr/file3/05_HTS_100.zip That is truely revealing. I played a little with it and I would say that it is likely that the addresses spaces in use are at 0x1000 and 0x30c. Possibly one of them are the flash and the other the ram. (using 'm68k-elf-objdump -mm68k -D -b binary HTS_100.frg' of course to dissassemble it) The most used subroutines (by grepping for 'jsr'): 199 0x30c45424 172 0x12cc 82 0x30c71370 81 0x30c557ac 63 0x1340 61 0x30c4fa10 61 0x30c4f7bc 60 0x30c70efc Perhaps the start of the .frg file can be what should be at address 0x1000 since at index 340 (the fifth most commonly called jsr) there seems to be a tiny function that moves data from d0 to the stack and then it calls 0x30c4f7bc. It looks like some kind of function dispatcher that could be actual code. I'm not sure this is actually usable for anything, but here it is! ;-) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: MPeye HTS-150
On Wed, 14 Dec 2005, Tim Schmidt wrote: Based on the descriptions of the player's function that I've found on-line, while playing, it supposedly spins up the disk, copies several megabytes of data to it's ram as a buffer, and then spins down the disk. In other words, the ram is there as a buffer and not much else. Well, that's a description that fits most (all?) disk-based music players. The question is only how much of the ram that is used for buffer and what else there is in there. I would say that the addresses used in the firmware indicates that there's code in at least parts of the ram. I would assume that executing in ram is faster than from flash. Of course the CF5249 also has 96KB internal ram. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: MPeye HTS-150
On Wed, 14 Dec 2005, Steve Moskovchenko wrote: A sibal jola jjajungna jakku ssang soriman nane!!! Does anyone have any idea what this could mean? According to Jungti1234 (Korean user on IRC), the phrase is roughly translated into motherfucker shit pair voice sounds constantly!!! What also might be interesting is that he also said that The company became dishonor. and MPeye was ruined. Whatever that means... (logged in today's dec-14-2004 IRC logs) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
daily build meta info
Hi Since people (Membrillo and Christi at least) started to write tools and offer services that download daily builds, I've now added an automatically updated meta-data file with the date of the most recently available daily builds: http://www.rockbox.org/daily/build-info This file is generated immediately after the last package is built in the daild build procedure. (The last few days it seems this gets written around 05:15 UTC) Using this, you can ignore what time zones and time of build we use, just get this file and you know what date to use when you check for daily builds to download. I could very well add more info to this file, should anyone come up with a need for other automated data about the daily builds. Enjoy! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: bmp support in the build system
On Mon, 26 Dec 2005, Linus Nielsen Feltzing wrote: Any comments/suggestions welcome. I like it! I only scanned the patch very briefly, but I'm very much FOR the idea and concept! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Dynamic memory allocation?
On Tue, 3 Jan 2006, Tobias Heimann wrote: I assume that this list doesn't allow attachments to show you any screenshots, but the game is coming along nicely so far... Hint: there's a wiki nearby... :-) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: IPod video?
On Mon, 30 Jan 2006, George Styles wrote: Is video decoding possible in theory? or does it use a undocumented propriority decoding chip? Everything on iPod is undocumented propriority chips, but on the video model there's a separate undocumented propriority chip used for video. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
My vote for BMP cache removal
Hi I'm not at all fond of the BMP cache thing that was added the other day. I think it bloats code, is complex and is the wrong answer to the minor performance problems we might have when loading WPS configs with large amounts of pics. I'd rather see us move towards using a single BMP with chop instructions for what to use. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Build error on my Archos targets
On Wed, 1 Feb 2006, [EMAIL PROTECTED] wrote: (Cc'ing this reply to the dev list where this seems to fit better.) i cannot compile the latest builds for my archos V1. The firmware/decompressor directory turned out to be missing in the source archives. Get it from CVS, a bleeding edge source tarball or tomorrow's daily... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
The Rockbox International Developers Conference 2006
Hi friends! Daniel Stenberg and Linus Nielsen Feltzing invite YOU to participate in the Rockbox International Developers Conference 2006, to be held in Stockholm Sweden during the weekend March 18-19 2006. We thought we'd get together for a two-day Rockbox hacking session, and that it would be cool if there were some other Rockbox devs who would drop by and share the fun. If you consider or actually intend to come, please drop us a note about it: [EMAIL PROTECTED] We'll arrange a proper location/room and facilities based on how many that actually plan to come. The same goes for beds and similar in case you don't mind mixing with us and our families to keep your hotel budget to a minimum! ;-) The agenda for this two-day Rockbox mania will of course be discussed so that we'll make something really good and worthwhile out of this unique opportunity. This info and upcoming updates are kept here: http://www.rockbox.org/devcon2006/ Regards, Daniel and Linus - Rockbox hackers
Status of some ports to new targets
Hi I thought I'd just sum up my perception of a few current projects aiming to produce Rockbox ports. If you have one of these players, join up and get things going. We need skilled and interested people in every camp! (Listed in no particular order. The mistakes and errors are most likely my own.) iAudio X5 Linus and I have this player. There's some very basic code that generates a checksum for the firmware image already in CVS, and the SDL simulator can build an X5 simulator already. This is similar to H300 hw-wise (coldfire etc). iAudio M3 There are some scans and research about its hardware in the wiki. Seems to be similar to the X5 hw-wise. Toshiba Gigabeat Marcoen Hirschberg has one and works on a port. He received the Linux sources from Toshiba, but they are of course incomplete. This uses a Samsung ARM9 core. iriver H10 PCB scans available. Resembles some of the iPds a great deal. Should make it possible to do a port if there's any skilled person with such a unit around. iriver iFP7x0 Tomasz is progressing along fine. This a 256MB flash player that uses an ARM7-core. iriver PMP Nothing has started. There's a linux source code from iriver available, but it is far from the complete works. Some people express a wish but none has stepped forward and did anything real just yet. This uses an ARM7 core with a TI DSP built-in (DM270) iPod Video Rockbox works on it, but there's no audio. No one seems to have worked very hard yet at figuring it out. This probably takes some dissassembly. Otherwise this of course resembles the Color and Nano models. iPod 3rd generation There's work in progress. Patch is available. iPod 4rd generation greyscale LCD This should be fairly simple once the 3G port gets in, since they seem to have the LCD code in common. MPeye HTS-150 Tim Schmidt showed interest and will on the dev list to attempt to make Rockbox run on this SCF5249 (coldfire) based player. MPIO H-series Seems to be mentioned every now and then by people. There's some internals info about the H200 model in our wiki, but no real work has been done. Archos Gmini No one ever took up the work where 'jyp' left it. This port is fading away... This player has a very different architecture (CalmRISC CPU etc). ... did I miss any? Did I forget any signification change or detail? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Diffing to current cvs (was Re: Lyrics)
On Wed, 8 Feb 2006, Burelli Luca wrote: Side note: anyone knows if/how to change the diff command used by cvs? I'd love to have cvs diff call vimdiff, but haven't managed to find out how. You don't, cvs uses an internal diff. But you can easily extract two versions from cvs and run whatever diff tool you like on them. I believe tortoisecvs and similar GUI tools offer this service more or less built-in. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: MSDev sim project?
On Sun, 12 Feb 2006, Thom Johansen wrote: The sim used to be able to be built in MSDev, but not anymore. However, the SDL sim _should_ work fine in MSDev after you've set it up (assuming no Cygwin/UNIX specific functions are used). I'd be very surprised if that worked without a sufficient amount of hand editing. The whole build system for Rockbox and the sim is currently quite GNU make and gcc centric. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Simulator Changes
On Sun, 12 Feb 2006, Dan Everton wrote: I've got some SDL simulator changes pending (sound.c is now implemented like the actual hardware, backlight works, etc). However committing these changes will break the X11 and Win32 sims as the stub implementations of these functions are no longer there. If you really can't make the x11 and win32 ones to build and this is a good change, then I'm all for moving this way. We've been talking about ditching the separate x11 and win32 ones anyway so it could just as well be done now. IMHO. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: The Rockbox International Developers Conference 2006
On Thu, 2 Feb 2006, Daniel Stenberg wrote: We thought we'd get together for a two-day Rockbox hacking session, and that it would be cool if there were some other Rockbox devs who would drop by and share the fun. Replying just as a reminder. We're now 7 persons who are determined to show up. We have room for more! Details here: http://www.rockbox.org/devcon2006/ I think this is a nice opportunity for some PR and publicity for our project: We've been contacted by at least one community-site admin asking about this event, questions were asked on the Neuros list about the chance of any Neuros representative going and I've tried to get some tech-style Swedish journalist to cover the event, but so far I don't think we've attracted much interest from outsiders. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Forum down?
On Fri, 17 Feb 2006, gl wrote: Forum seems to be down... And now Jeff has it up and running again! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
A Tracker on the Move
Hey Stop using the sourceforge tracker *now*. All data is being translated. New tracker being announced very soon. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Archos special build
On Fri, 24 Feb 2006, Tom Cole wrote: Would the developers mind if I created a wiki page on the Rockbox site and hosted my special build there? Here's _my_ view of it: In general I have no problem with hosting custom things in the wiki. But, when it comes to custom/alternative Rockbox builds and things like that I hesitate. The reason for my hesitation is that when we start offering these builds from rockbox.org, people will assume that they are true products of the project and that they are official and supported. I have no problems with people building and offering customized Rockbox builds, but I don't want such builds to be mistaken for official Rockbox builds. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: amiconn: apps plugin.c,1.151,1.152 plugin.h,1.156,1.157
On Sun, 26 Feb 2006, [EMAIL PROTECTED] wrote: Finally - grayscale library support for the simulators. Lovely! Nice work Jens! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
que?
Christian, Can you please enlighten us what that em84xx[*] stuff is you committed to our CVS the other day. I was expecting a big explanation posted to this list, but so far I haven't seen any... [*] = http://www.rockbox.org/viewcvs.cgi/em84xx/ -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: building/distributing plugins separately (Re: make file help please)
On Fri, 3 Mar 2006, Frederic Devernay wrote: I think the clean way to develop a plugin would be to be able to build it from another directory than the rockbox build dir. Linux developpers may think about how kernel modules can be built from any directory, making it easier to distribute them separately. I don't think anyone would mind fixes and changes that would make that easier! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Patch: Optical Out setting extension for Battery/Charger.
On Sun, 5 Mar 2006, gl wrote: This extends the 'Optical Output' setting to 'Off / Battery Only / Plugged only / Battery Plugged' on platforms that support it: http://www.rockbox.org/bugs/task/4774 I think this calls for a revisit of an old idea: load a custom config file at specific events. Like when running plugged-in etc. That way you could have one config file for when running from the mains power and that could enable optical out, while the standard config would have it disabled. Having options doing this magic on their own seems like the wrong way to go. Or am I missing something? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Signing off.
On Wed, 8 Mar 2006, gl wrote: After Linus was about to commit one of my patches, it turns out the project leaders are not willing to accept contributions under a pseudonym. This may be normal in the GPL world, but for someone from the Windows / BSD license world, this seems utterly bizarre. Since we had this debate the last time, a large amount of Open Source projects have gone a lot stricter in this department and we are certainly not alone in this stand-point. Some of them are BSD-style too. It is not about what license we use. To me, it is about who does what in a legal / copyright angle and that we are a real project with real people using real names. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Signing off.
On Wed, 15 Mar 2006, Bluechip wrote: http://www.rockbox.org/twiki/pub/Main/DataSheets/mas35x9f_2ds.pdf No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of Micronas GmbH. Then this should be removed. Immediately. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Signing off.
On Wed, 15 Mar 2006, Bluechip wrote: How exactly is it unlicenced? http://www.mp3licensing.com/royalty/ Björn pointed this out. You refused to respond (to that too). they haven't sued anyone yet Then The Rockbox-Three are probably safe then :) Why would anyone sue one of us even if this was true? Rockbox is not a formal organization of any kind and I don't see how one of us is personally responsible for Rockbox as a whole. Possibly we could be blamed for distributing it, yes, but then I'd guess they'd sue the admins or the owner of the server(s). The Rockbox-Three were VERY clear about their stance on Trademark infringement when they insisted on changing the name of the Tetris plugin. I use this example merely to highlight the duality within the Rockbox 'code of conduct' We are clear and that has not changed. We haven't been made aware of any trademark infringements to my knowledge. Now when you've brought it up and I checked around I can only _assume_ that you are talking about our use of the name 'Bejeweled'. Is that so, or can you please clarify? You speak in vague terms. As I said before, The big-3 (ala Rockbox.org) have claimed that their rockbox.org is a domain and there are lots of more people than three that support and produce what we do in the Rockbox project and that result is hosted on the servers using that domain name. Feel free to read up on the subject if you wish to understand fully, most correspondence is publicly available :) ... I have no interest in proving anything. Merely highlighting parts of reality which have been carefully shaded by The Rockbox-Three. The info is publicly available and yet carefully shaded? (Not that I even understand what info you're talking about in either of these cases.) It's just another requirement, along the lines of 'rockbox is written in C and assembly' and 'comments start with /* not //'. The world is full of requirements. Yes, that's another fine example of a requirement which is only relevant when The Rockbox-Three say it is relevant. Well spotted! Did you pick the same example as me? Do you actually think that only we three do all CVS commits, code reviews and enforce the source code rules? Are you aware of what amounts of code we have? Are you aware of the amounts of contributions and submissions from people we get? Do you understand how much time we already spend on this? Yes we want the code to follow the source code rules. Lots of mistakes and sloppiness slip through anyway and from time to time we do raids to adjust code to be more adhering to our guidelines. Yes there are still many rule-breaking source codes around. One day we'll probably fix the cases you mentioned here. I have no doubts you can also find a bug or two in the code. A conspiracy by The Rockbox-Three must be the only answer to why they are still present. I mean, it can't be as simple as that mistakes happen? Now, the good part about open source is that if anyone is unhappy with the project they can take the source and start a new project somewhere else. If you and the rare few others who stand by you on your conspiracy-crusade would be seriously concerned, then you should do this. But no, as we've seen for the last several years, you just continue your whining and complaining. I don't think I'm alone in wondering what the heck you're still doing here. Everything we do seems to be wrong in your eyes. You don't contribute with _anything_ useful. Yet you're still here. Year after year. I have no doubt that you'll continue your endless effort until the end of times. I think I'll continue to respond to your outbursts every now and then. It'll keep me amused. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
A Devcon 2006 Story
Hey folks I just wanted to mention that you guys that didn't manage to come to the devcon really missed a great event! Not only did we have a great time socializing and actually meating the persons behind the nicks and names we've been seeing online for years, we also managed to discuss and deal with _all_ items on the agenda, and most of them with a great and at least in my view satisfactory outcome. I'm absolutely certain that users and other devs will see and appreciate the outcome from this, not the least in things like the already in-progress work on a 3.0 release. (Yes, we should do some kind of summary of all the talks of the agenda items and publish.) Random Memorable Happenings: - Christi and Brandon arriving several hours late after a having got off at the wrong bus stop, taken the subway and gotten off at the wrong station etc etc... - The What are you sinking about commercial - The massive interest for our webcam on IRC and elsewhere. It help us feel almost like #rockbox were with us there. Thanks and credits go to: - everyone who has donated money to the project, as we used some of these funds for drinks, snacks and food during the devcon. Please continue donating for the benefit of the project so that we can continue to support and sponsor development-related activities. - Jens, Jörg, Christi and Brandon for being devoted enough to cross country borders to come here. - Contactor for letting us use the offices that served as a pretty neat surrounding, with a fine network, webcam, printer, conference room, coffee machine and even space and sofas for sleeping. - Haxx donated the shirts. And before asking, we still have not quite decided on how to proceed with the remainders of the shirts we have. I'm open for interesting suggestions. Some thoughts for Devcon 2007: - We should probably set a date even earlier than this year to allow people to plan for devcon even longer in advance. - We should prepare for the food situation slightly better, at least if we'll be situated at the same place or in a similar surrounding. We did have to resort to backup plans several times... -- Daniel Stenberg A Devcon 2006 Organizer
Re: Ipod 5G serial
On Tue, 21 Mar 2006, jkubik wrote: Is anyone working on the Ipod 5G serial interface at the moment? If so, where are you? Since Christi hasn't shown up here yet since devcon I'll fill in and mention that she seems very interested in getting the serial port going on her iPods. We talked about it at devcon. Using the serial port you could get a gdb stub going, use it for debug outputs, make multi-player games and more... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Ipod 5G serial
On Wed, 22 Mar 2006, Jonathan Gordon wrote: was there any discussion on how to make it more generic.. tihnking about usb-otg on the h300... Since none of it is close to be supported yet, talking on making non-existing things generic seems very premature to me. I believe usb-otg is a lot more complex and potentially advanced than supporting a mere serial port is. Still, let's add support for it first and then see what we can do generic and what not. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: half-idea for #ifdef and key deifnition hell...
On Thu, 23 Mar 2006, Jonathan Gordon wrote: im not entirely sure :p i was hopeing this msg would get more responses... When we discussed this at devcon, we decided there was no way we could squeze such a huge overhaul into 3.0. That might also be a reason why not so many replies: we work hard on getting the stuff already marked as 3.0-material to work as they should. At least I am. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: VMWare Environment
On Fri, 24 Mar 2006, Mark Bright wrote: Downloaded from CVS, and build the H1x0 build, zipped it - no errors, 125 seconds The next big gain to get even faster builds on Linux is to install and use ccache when building. 1. install ccache 2. run configure as 'configure --cache' 3. Enjoy faster (re)builds -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: VMWare Environment
On Sun, 26 Mar 2006, Mark Bright wrote: 2. run configure as 'configure --cache' I am assuming that means '../tool/configure --cache' To prepare the make file to use the cache? Right. In fact I even meant: ../tool/configure --ccache That is the option is named --ccache with two 'c' in the front. ccache is a system that caches compile results so that subsequent invokes with the same conditions simply reuses a previous object file instead of doing the same compile again. Now, is there some way to speed up the manual :-) 40 seconds is starting to feel like a long time... Sorry, no fancy caching system up my sleeve for that one! ;-) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
cvs builds
Sorry guys, It stood still for a few hours during the afternoon, I hope it's back up again now. I'll check it out closer again tonight. My bad. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Rockbox shirts
Hey dudes! For the devcon2006 event, we got a bunch of Rockbox shirts made that we handed out to the attendees. There are about 17 of them left in my house, that I am now about to pass out to interested people. These shirts are sponsored and donated to us by Haxx (http://www.haxx.se/) Okay, so here's the deal: While I don't mind sending them away to all that wants one, I don't feel like paying postage and packaging from my own pocket for them. Shirt facts: * ~280 grams each (they're produced using a 210 grams/m2 material) * Rockbox blue only * 100% cotton * Available in XL, L and M of various amounts * 10cm wide Rockbox logo (two-color simplified version) on the chest * Shirt pics = http://daniel.haxx.se/rockbox/devcon2006/ As you can see on the picture, they are not t-shirts but I don't know the proper english word to describe them. * For reviews on the print and quality of the shirts, I guess there's a few devcon people that can fill in some info! ;-) To get a shirt, do like this: * mail me privately at this address, include 'shirt' in the subject * prepare to pay me 80 SEK (10 USD) within Europe, 88 SEK (11 USD) world wide for postage and packaging. Payments will be accepted using paypal or international money transfer, details taken privately. * if you want more than one, like if you get together to decrease shipping overhead, it'll of course be less than the 10 USD per shirt. I'll have to check that on a case-by-case basis * state what size you want, and if you can consider getting a different size if your chosen size runs out. I have XL, L and M sized shirts of various amounts. * please also state if you'd consider paying somewhat more to get a shirt from a second round of shirts, see below Donation! Everything you add to the payments besides the amounts given here will be handed over to the regular Rockbox fund, making this a good opportunity to sponsor the project a bit. The fund is of course always used for Rockbox-related activities such as buying development equipment, target players, food for developers at devcon and more. For the case where there are more than 17 shirts requested, I will: * Use a time window during which I accept requests, a week starting now. * Prioritize the shirt-giving to (active) developers * Consider producing more shirts for a second round, but only if there are a fair amount of people who'd be willing to splash out another 7 USD for it (totalling in 17/18 USD for a single shirt shipment). -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Rockbox shirts
On Thu, 30 Mar 2006, Ronald Teune wrote: Aahh... you look so happy in that shirt :-P That's how the shirt makes you feel! ;-O -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: source download link broken
On Tue, 4 Apr 2006, [EMAIL PROTECTED] wrote: the link http://download.rockbox.org/daily/source/rockbox-daily-20060404.tar.gz should point to http://www.rockbox.org/daily/source/rockbox-daily-20060404.tar.gz Thanks for telling! Actually, this link is now pointing to: http://download.rockbox.org/daily/rockbox-daily-20060404.tar.gz (download.rockbox.org is less loaded and has much greater bandwidth) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Bug in screen_access.c affecting all drivers.
On Tue, 4 Apr 2006, gl wrote: My problem is that Please. Not again. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Bug in screen_access.c affecting all drivers.
On Thu, 6 Apr 2006, gl wrote: Agreed - but you guys can't have it both ways either. Either the policy exists because you genuinely don't want to work with anonymous users, then don't accept contributions through the backdoor. It makes the policy a joke. Small and trivial changes will always be accepted and used with or without the user being known or anonymous. We've always done it like this and your case is not an exception. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Iaudio X5 using lcd-h300.c
On Mon, 10 Apr 2006, RaeNye wrote: I've skimmed through lcd-h300.c and saw references to the H300's screen size (220x176) in lcd_update() and flip_lcd(). x5 is not using lcd-h300.c. It uses the lcd-x5.c. X5's port obviously /has/ LCD support, but why does it work if the constants are off? They're not off in the correct file! ;-) You should check the firmware/SOURCES file to see what files that are built for various targets. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Fwd: Remove PluginJewels from RockBox downloads immediately
On Sat, 15 Apr 2006, Tomas Salfischberger wrote: You can ask him to contact someone by phone, and explain his problem, just to make sure he understands what we do etc. I think Daniel or Linus would be a good choise for that phonecall, or some native English speaker with legal knowledge. (Do we have a lawyer in the house? :-)) I would say that a fair and just response would be to kindly ask the person/company in what way we could possibly violate their copyright. We use no fragments of their product, and me knowingly they have no patent on the ideas (for those areas of the world where software patents would be valid). I think this is just an attempt to make us stop shipping Jewels, but without much legal backup. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: Remove PluginJewels from RockBox downloads immediately
On Tue, 18 Apr 2006, Björn Stenberg wrote: I think we have the law on our side. The images are not copied from their game and they aren't identical, as anyone can see. The only claim they could make would be that our images are too similar to theirs and thus could be considered plagiarism. The only way to really find out if we are too similar is to battle in court. However, I don't think we'd loose anything by being soft and simply modify our jewels somewhat so that they don't look so similar to their versions, just to be nice. After all, I'd rather have our game have a more unique Rockboxesque look than being a simple copycat. The only thing is that the existing jewels are really good-looking and it would be a pity to replace them with a set that aren't at least as nice. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: FMR ucl directory and TagCache issues
On Thu, 20 Apr 2006, Simon M. wrote: I would suggest to put the Tagcache and dircache options together. For instance in system/caching Personally I can't see Tag Cache as a cache at all so bundling the dircache (which I do view as a cache) with Tag Cache like that would feel highly unintuitive to me. I actually propose we call the feature tagdb, trackdb or something like that. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Postponing Mayday
Yes, You knew it was coming and here it is: I suggest we postpone the planned 3.0 release 14 days to allow more time for bug fixing and debugging. Thus: release 3.0 codename mayday scheduled for release at May 15th instead. I also suggest that we have an optional second postponing to May 29th, should we need it, but that we DO NOT postpone it further beyond that date and then instead ship what we have with the bugs at that time simply being known bugs at the time of release. To sum up: we make an effort to kill the release-critical bugs within two weeks from now. Failing that, we kill as many bugs as possible in the two weeks following and then we release Rockbox 3.0 for better or for worse! The upside is that May 15th and 29th are still Maydays! ;-P -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: make the cvs build zips smaller?
On Wed, 3 May 2006, Jonathan Gordon wrote: ive setup my computer with linux and moved it downstairs so it can stay on 24/7 so youve got another build server if u want it (celly 2.4ghz, 512mb ram), the only downside is that my uploads are capped to about 20KB/s so uploading the 2mb zip actually takes longer than compiling... We're on 45 builds in the CVS table right now, and only 12 or so of them transfer anything back. But yes, adding a 100 second transfer time to the single build is of course no fun. so, my suggestion (also happens to decrease your bandwidth usage also) is to strip the non-comiled stuff into a seperate zip for all targets.. (fonts, docs, wps, cfg, etc). removing this from the build dropped 1mb off the zip size... which would work out a fairly big bandwidth saving for everyone seen as these dont really need to be updated frequently... (actally english.lang prob would need to be in the zip...) This is repeatedly discussed and we've been planning on doing something like this for the 3.0 release. I can't say I have all details sorted out in my head yet as in how this will affect users and how users will know when they want to get a full package and a subset package. But I don't think having the cvs builds do light packages is a solution to anything as there will still be people who want to download a full version and then we need to offer such ones. Doing full/light packages will help the users who download packages, not build servers that create them. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: make the cvs build zips smaller?
On Thu, 4 May 2006, Manuel Dejonghe wrote: 7zip is a bad idea and best case scenario is that you'll only see 15-30% filesize savings. I don't see the point, as the original concern was cpu power bandwidth Yeps. In my quick and naive zip/7zip compression tests I did a number of months ago, the typical gain for a rockbox.zip was in fact more than 30%. Since we're talking about packages that are downloaded thousands of times *every day* we would also cut down on bandwidth for the server(s) hosting the downloads. (If we also count the daily builds.) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: X5 dual boot revisited
On Mon, 8 May 2006, RaeNye wrote: Cowon's OF might rely on what the preloader has done, and RB bootloader thrashes everything. Thus, I must decide ASAP which firmware to load. The iriver versions don't do it like this and they still work fine. The conclusion it MUST be done like this is a bit drastic IMHO. As I said before, I suspect the problem originates from i2c-generic using global variables before initialized by RB-bootloader. Having a more efficient PCF50606 driver is important (I nagged about it before) but irrelevant to the progress of the dual-bootloader. After PCF50606 driver is re-implmented (possibly by yours truly), it makes perfect sense to adjust the dual-bootloader to use it, but it is not a prerequisite IMHO. We can re-iterate this many laps, but so far extremely little Rockbox code depend on anything in any original firmware. This (depending on the cowon firmware code) would probably be the biggest dependency we have and given what we've seen in the past: it is very likely to bite us one way or another in the future. I don't see you adding any new reasons for your standpoint and I think I've emptied all my arguments. So, I'm still against it. If the i2c-generic is so bad (it has been publicly admitted numerous times that it was written primarily to work not to be the fastest - and thus it has lots of room for improvements) it cannot be used, I would consider that a bug and we should fix it. Also, the efficiancy is hardly a factor in the bootloader. But again, as I said in the bug tracker entry, if we really cannot fix our drivers to work in this bootloader I am willing to allow this (in my view) hackish approach just to get something working added. We can always fix things more later on. I intend to add an additive dword-sizes checksum over the preloader's code. I cannot signal it's not working with either leds, the lcd or any hardware (since that would require PCF50606 funcs...) I suggested a led flash since that was the only feedback I got on the dual boot patch that didn't work! ;-) but I can fallback to booting RB. ... and it sounds like a much better fallback than what I suggested. OSS is all about choice, hence I don't intend to tell users anything like The dual-bootloader will only boot RB by default because I'm a RB dev as much as grub won't tell you I ain't booting your Windows by default. Even if the official version supports only RB-first, it is easy to reverse the order (as people in iaudiophile.net's forum have already done). In my view, Open source is primarily about choice because people have the source and can do whatever they want. It doesn't mean we have to add every imaginable feature ever asked-for as an available option. I don't feel particularly strongly on this topic, I just think its a waste of time to add functionality to bootloaders to reverse the default boot order. People who really feel they need it can always just make it do that anyway. And we certainly aren't grub. Finally, you always run fsck, which calls the needed worker (e.g., fsck.ext2). If your system has ReiserFS, you'll have fsck.reiser; if not, you won't need it or even have it compiled. The very same should be done with mkboot. I could certainly agree to a system like that, even if it feels a bit like overkill to me (with only iriver and iaudio around). But I haven't seen you do that and that's why I was advocating a way to make a generic mkboot for multiple targets. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
rockboxdev.sh
Hi friends I've written a little shell script called tools/rockboxdev.sh. When run, it asks you what target architecture you want a compiler setup for. Then, it downloads, unpacks, builds and installs binutils and the gcc cross-compiler for you. It should work for SH, arm and m68k and for the SH case it also applies the necessary gcc patch. This should work on all *nix like systems and cygwin (afaik), but I'm interested in reports and feedback on details and possible problems. Enjoy! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: rockboxdev.sh
On Fri, 26 May 2006, Sander Sweers wrote: Thanks :) Although gcc does not build for me the script works. I have never had =gcc-4.0.x build for m68k-elf so it is not the scripts fault ;) On what system using what native gcc? One comment, it fails if $dlwhere does not exists. This should make it work. if test ! -d $dlwhere;then mkdir $dlwhere fi Yeah, I guess it can do that... Thanks. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: format of rockbox image pixmaps?
On Fri, 26 May 2006, Bill Janssen wrote: 2) I can't find the documention of the image formats for the various devices. The closest thing seems to be the code in firmware/export/lcd.h. Is there any other source for this information? Would someone like to try an explanation? The internal image format is always in the same way as we have the frame buffer, which is the same way the target's LCD likes it. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
On Mon, 29 May 2006, bk wrote: Obviously there's some problems to deal with, since we've been in a freeze forever, there's little CVS activity and no clear indications on when a release might happen, what's holding it up or who even makes the final decision. Yes, there are too few developers actually focused on fixing the bugs and remaining issues. The majority of us all are just waiting for others to fix them so that 3.0 is released and the freeze is lifted. Personally, I say we basically are down to two options: A) drop H300 from the release and ship Rockbox 3.0 for Archos and iriver H100 on friday. B) drop the entire release and make another release attempt later on when we have sorted out the remaining playback/voice issues and possibly a few power related issues on H300. I think I favour version A here. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: Release policy and coordination
On Tue, 30 May 2006, Bryn Smith wrote: Please don't take this the wrong way, but it doesn't really encourage newcomers to the project when they come across masses of uncommented code. We don't write Rockbox in order to welcome newcomers. We write Rockbox for the fun of it. We're all doing the best we can given the time we can spend. If you think of improvements to some areas, then please go ahead and improve them and submit patches. I think we all agree on that it would be great to have very well commented code with huge documentation and up-to-date descriptions of code flow and concepts. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
bug report closing (was Re: Release policy and coordination)
On Tue, 30 May 2006, Zakk Roberts wrote: iPod bug reports, and the policy is not clear to me on how aggressive we should be about closing them because they aren't supported models. I think several of the 'should-be-fixed' ones are also still open even after fixes are committed with comments from the devs asking is this fixed with latest CVS? and getting no response; My position on this: *all* bugs that have an outstanding question that needs to be answered for the bug case to move forward SHOULD be closed if nobody replies to the open question within two weeks. If the submitter happens to be legitimately away for that period, he/she can always re-open the task later or submit a new bug report. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Release policy and coordination
On Fri, 2 Jun 2006, Dominik Riebeling wrote: a quick idea on this: how about packaging the (still draft, but hopefully this will be better for 3.1) manual to the release fullzip archives? I totally agree that's what we should do. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Loading memory?
On Wed, 7 Jun 2006, [EMAIL PROTECTED] wrote: But now that I've increased the utilized memory on my ipod to 64MB, thanks to Petey Leinonen's patch, will Rockbox automatically load more tracks per spin up? Or is additional coding required to take advantage of the additional memory? AFAIHUI, the whole point of that patch is to enlarge the buffer used for compressed audio for 64MB iPods, so yes Rockbox will take advantage of that automaticall and load many (more) tracks at once into memory. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Where to post? Too many options?
On Wed, 7 Jun 2006, [EMAIL PROTECTED] wrote: Lately, I realized there's an online forum. Where should we be posting? ... and you'll soon find that iriver users and iaudio x5 users also have user forums elsewhere where they post and discuss rockbox-related subjects as well! I prefer the lists, mostly because I only need to monitor two: rockbox and rock-dev; I just look at what's new in my inbox and read any with interesting-to-me subjects. Then use the lists. I personally prefer the lists too. it would be nice to get email notification of new patch-tracker topics (there's probably a setting for this that I need to figure out). Subscribe to the rockbox-sf mailing list, it gets mailed on all patch tracker changes and submissions: http://cool.haxx.se/mailman/listinfo/rockbox-sf tailored notification of CVS modifications -- e.g., right now button.* and lcd*.* are of interest to me I would suggest you subscribe to rockbox-cvs and filter the mails on the subject to show you the ones you are interested in: http://cool.haxx.se/mailman/listinfo/rockbox-cvs And wiki mod notification would be nice too. I believe it is possible with some plugin to twiki, but so far we haven't tried anything like that. we're seeing a localized explosion of modalities and information, and I'd like some way to get something like an RSS feed or (better) email notification. I expect the explosion to continue even more as the amount of both users and developers are still increasing. We've surpassed the point in which most of the core devs could keep up with most of all public discussions that concerned Rockbox. This is the natural development of a project growing big. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: subversion
On Sun, 11 Jun 2006, [EMAIL PROTECTED] wrote: I heartily second this. Having used both cvs and subversion, subversion is much better in its features and more user-friendly. There's no denying of this. We've been discussing and intending to switch away from CVS for a long time, and we all agree that Subversion is a better system than CVS. The question has rather been if Subversion is the best alternative to CVS for us and for how Rockbox is developed. I have written quite a bunch of scripts and tools on the server(s) that all are CVS-based and they would all require attention and modifications so a switch will require quite an effort. No undoable, just a bunch of work that so far has felt like I ohhh h not now please. And as a bonus: yours truly is involved and even has commit access in the Subversion project! ;-) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Daily builds and fonts
On Sat, 24 Jun 2006, Stephan Seitz wrote: Hm, could you insert into the fonts field (there the rockbox logo is and the links for latest and old) the date of the last change of the archive? Not easily, as the script that creates the font archive has no idea about any changes. It just builds an archive and I run that script every day. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Daily builds and fonts
On Sat, 24 Jun 2006, Stephan Seitz wrote: Okay, but within the archive nothing would change, wouldnt it? So if we could add md5sum/sha1sum (which would be a gould idea for every archive, I think), you could check this value. Yeps, we could do that! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Flyspray
On Wed, 28 Jun 2006, Paul Louden wrote: What do you mean by all patches are announced via an email? I think he refers to the rockbox-sf mailing list: http://cool.haxx.se/cgi-bin/mailman/listinfo/rockbox-sf -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
mi4, BL and more
Hello I just wanted to put your attention to the fact that we now have a first (en/de)crypt tool for (some) mi4 files. All details on my mi4 page: http://daniel.haxx.se/sansa/mi4.html We can use some help to get the rest figured out as well! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: mi4, BL and more
On Sat, 1 Jul 2006, RaeNye wrote: Where is this code from? The source code comes from 'MrH' who has RE'd and analyzed the mi4s and BL files I host. I presume reverse engineering of the BL files (surely explains negating the constant). If so, why can't we RE (or just take the keys off) other header versions? We can, and I'd say that's what we're doing = mi4code.c is now updated and can now deal with Sansa's mi4 files too! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: dave: firmware crt0.S,1.73,1.74
On Mon, 17 Jul 2006, [EMAIL PROTECTED] wrote: Gentlemen, we have sound on the 3rd Generation ipods. Thanks to Daniel Ankers for debugging. It turns out the problem was simply that we were calling the FIQ handler incorrectly - everything else was fine. Super-cool! Is it time to add them to the daily builds now? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: ipod 3g (was: Re: dave: firmware crt0.S,1.73,1.74)
On Tue, 18 Jul 2006, Dave Chapman wrote: But if you can add them to the daily builds, I'll upload a bootloader to the wiki and adapt the install instructions to include the 3G. Added now! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: genlang -u
On Wed, 19 Jul 2006, Magnus Holmgren wrote: Every time I run genlang -u (under Cygwin), I get a bunch of error messages like these, seemingly for every existing string in the translated file: Warning: dest before line 8507 lacks quotes! Could it be a line-ending related problem or similar? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Sansa e260 running modified firmware
Hey peeps Background info: http://daniel.haxx.se/sansa/mi4.html Today I managed to flash my e260 with a modified firmware (just the original one with an altered text when I insert USB). This proves we know enough to generate .mi4 files to upgrade these players with. (And this works without patching the original BL file.) Before I had the success, I got to try upgrading to a bad mi4 image and found out that the player then nicely allowed me to enter recovert mode and mount a small partition that I could copy a working set of firmware files to and have them used! So, we can now start figuring out and testing code on the unit for real... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: raenye: firmware/target/coldfire/iaudio/x5 pcf50606-x5.c,1.1,1.2
On Sun, 23 Jul 2006, [EMAIL PROTECTED] wrote: Accepted FS #5696 by yours truly. Raenye, please tell what the changes are and why in the commit messages so that we don't have to lookup external resources just to understand them! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Question about targets for langv2
On Mon, 24 Jul 2006, Matthias Mohr wrote: Is it possible to prepend several target names to one string, like follows: ipodcolor,ipodnano,ipodvideo,ipod3g,ipod4g,ipodmini,ipodmini2g: some string for all ipods Yes, that's possible and supported already. Exactly like the above example. Or do I really have to create one line for each target? Nope. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: shared library support?
On Mon, 24 Jul 2006, Bill Janssen wrote: would like to bundle them up as shared libraries instead of statically linking them into each plugin. Is there any standard way to do this with Rockbox? Does it even have the idea of shared libraries which applications (plugins) use? No, they have no idea and we have nothing resembling shared libraries in Rockbox. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: shared library support?
On Tue, 25 Jul 2006, Bill Janssen wrote: Note that plugins themselves are shared libraries; it wouldn't take much to extend the plugin API to include a function to allow plugins themselves to load other shared libraries, as long as they do so before trying to look at (or use) the plugin buffer. But plugins load at a fixed address, which you couldn't do with these shared libraries if you if you would try to load them into a dynamic address. So it would require a more sofisticated loader. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Question about targets for langv2
On Sat, 29 Jul 2006, Magnus Holmgren wrote: ipodcolor,ipodnano,ipodvideo,ipod3g,ipod4g,ipodmini,ipodmini2g: some string for all ipods Yes, that's possible and supported already. Exactly like the above example. Any particular reason for it not being used yet? I mean apart from no-one has taken the time to do it. :) I think it's just another thing no one has yet done. By the way, would ipod*: work for the above? That'd be nice... Yes it does! I tried doing it for a few strings in the Swedish translation, and noted that you have to put the default string first, then any target specific ones. Not a problem, but good to know if you want to try it out. :) Ah, right. The LangFiles wiki page certainly needs some updates... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: raenye: bootloader main.c,1.31,1.32
On Sat, 29 Jul 2006, [EMAIL PROTECTED] wrote: Index: main.c ... +#ifdef IAUDIO_X5 +#include backlight-target.h +#endif Shouldn't this #ifdef be for TARGET_TREE ? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: raenye: bootloader main.c,1.31,1.32
On Sun, 30 Jul 2006, RaeNye wrote: It's relevant only to X5 That's because X5 is so far the only target that uses the target tree approach - but we plan to move all targets to use it. (Linus pointed out the docs for it.) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: dan_a: apps main.c,1.178,1.179
On Thu, 3 Aug 2006, [EMAIL PROTECTED] wrote: Initial work for coprocessor support on iPods. FS#5755 ... +/* This is the entry point for the coprocessor + Anyone not running an upgraded bootloader will never reach this point, + so it should not be assumed that the coprocessor be usable even on + platforms which support it. And for the devices using PP chips without being ipods? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
SanDisk Sansa e200 owners, join in!
Hey Just wanted to mention that we now have a bootloader embryo for SanDisk Sansa e200 players committed to CVS, so now is a perfect moment for lurking Sansa owners to jump on the train. We know how to run code on target (and how to safely revert back to a functional original firmware) but we don't know much about to use LCD, read/write flash, read buttons or similar... I'll try to keep info and details about the reverse engineering progress here: http://daniel.haxx.se/sansa/e200.html Occational talks about it is also kept here: http://forums.rockbox.org/index.php?topic=3225.0 -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: mmmm: apps/lang english.lang,1.268,1.269
On Fri, 18 Aug 2006, [EMAIL PROTECTED] wrote: Bookmark support for I-river remotes, also renamed bookmark delete button as it has changed to RECORD - Sorry Linus ;) -*: ON+Play = Delete +*: RECORD = Delete Now now, what about those players that dont _have_ a RECORD button? -*: ON+Play = Delete - h100,h120,h300: ON+NAVI = Delete +*: RECORD = Delete And here too, why did you remove the support for non-iriver? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: tomal: uisimulator/sdl UI-ifp7xx.bmp, NONE, 1.1 button.c, 1.13, 1.14 uisdl.h, 1.16, 1.17
On Fri, 18 Aug 2006, Jonas H wrote: I still cannot build the iFP-7xx simulator after this commit. The build breaks with the following error: I'm also curious in what state this port is atm. Will it make sense to add builds for this to the cvs and daily builds soon? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: tomal: uisimulator/sdl UI-ifp7xx.bmp, NONE, 1.1 button.c, 1.13, 1.14 uisdl.h, 1.16, 1.17
On Fri, 18 Aug 2006, Paul Louden wrote: I vote requesting a proper bootloader, rather than the .wma hack. Other than that, from what I've read about the progress, limited playback is available and it works on 256mb and 512mb units. For dailies I agree we could have such a requirement, but I think there's a legitimate reason to add it to the CVS table even before it starts getting widely used, just to make sure it doesn't break by people's commits etc. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: tomal: uisimulator/sdl UI-ifp7xx.bmp, NONE, 1.1 button.c, 1.13, 1.14 uisdl.h, 1.16, 1.17
On Fri, 18 Aug 2006, Paul Louden wrote: Ah, yes... well I'm all for the CVS table. Can you do that and simply not put a direct link to the CVS build for it on the builds page? Yeah, they're totally individually controlled. There are 45 CVS builds but only 19 zips to download... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Archos Player taken out?
Hi friends Linus and I have come to the conclusion that the time has come to pull out Archos Player support from the main Rockbox sources. Removing this from the sources will of course not remove the existing download packages or whatever we have today that works fine for the Player. It will just make development from now on very restricted for that device. Reasons for doing this: o The Archos Players are very limited HW-wise and hardly anything added to Rockbox these days benefit Player owners. So there's not much of a point for Player owners to keep up with and use the latest. Most Player owners simply use one of the older releases and are fine with that. o Hardly any devs have Players these days or at least hardly ever use them. There's even hardly any users tracking the bleeding edge and thus we often don't even notice when we break functionality! o The Archos Player's very limited LCD and buttons are a burden in lots of GUI-oriented code. Ripping out the need for support charcells will simplify lots of code. How We Propose to Proceed o We set a CVS tag and create a CVS branch of the current code, the last combined Rockbox version with support for Archos Player. The name of the branch will be 'player'. o In the CVS HEAD (main development branch) we rip out Archos Player specific code, we stop doing daily builds etc covering the device. o We call out and urge a Rockbox Archos Player Maintainer to step forward to nurse the Rockbox player branch (as important bug fixes etc could go in) but perhaps most importantly to make a last full release of Rockbox for the Archos Player, including docs, voice files etc.
Re: my next crazy idea... rework the menu system
On Wed, 23 Aug 2006, Jonas H wrote: Furthermore, option bloat in my eyes is more than just code-size and code-readability. It's also the fact, that too many options make baby Jesus cry. Or at least, it makes it harder to find what you're looking for. Yes indeed. Of course, in that case, people will be unable to change certain options without having to use a computer. Maybe some sort of .cfg-file editor plugin could be created, which would then expose all available options (or maybe just the hidden ones). Another alternative used in some UI environments is of course the Advanced mode that until selected hides lots of the more esoteric options. However, that makes some options even harder to find... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Tagcache stops working when charge is started
On Fri, 25 Aug 2006, [EMAIL PROTECTED] wrote: I have the following problem with my H320 Do *NOT* reply to existing thread as a shortcut to create new ones. If you want to post about a new topic, write a new mail. You wreck the threading of mail clients and web mail archives. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: adc-target.h missing for sansa e200
On Tue, 29 Aug 2006, Kosta Welke wrote: Daniel, did you forget to check it in or is my build environment messed up? I blame a change in the build! ;-) But now I've committed a dummy version and the Sansa bootloader builds again. Thanks. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Tetrox renamed to Rockblox, for trademark reasons
On Wed, 20 Sep 2006, Mike Holden wrote: Apple and Apple are prime examples of how this works in the real world. Apple records sold records, and Apple corp made computers and software. However in the modern global multimedia market, both are treading on each other's toes quite a lot in terms of market areas, and they both seem to continue without problem. You mean apart from the fact that Apple Records sued Apple Computers for several million dollars and lost? ;-) According to news articles a few months back, they had a deal that Apple Records thought Apple Computers broke when they entered the music business with iTunes and iPod. Regarding trademarks on the name Rockbox, the german site rockbox-lounge.com has got a CD-letter from a german company which seems to own the German trademarks for Rock Box and Rock-box. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Question about V2 .lang file format
On Wed, 20 Sep 2006, Andrew Hart wrote: I'm in the midst of writing a utility to build .voice files using the new V2 lang file format. Uh, genlang -o was made just to let you use the old scripts without having to do this! I've looked on the Rockbox site for info about the .lang file format and found the docs about updating language files which gives a description of the .lang file format. However, it does not explain the user: lines that appear in phrases. There's some additional info to read in my original description of the plan: http://daniel.haxx.se/rockbox/langv2 But to take it short, the 'user:' field is not used yet. It is meant to describe if the phrase is for the core or for a (named) plugin. Oh, and while I'm at it, what encoding is used for the quoted strings in .lang files? Is it ASCII, UTF8, another flavour of Unicode or code-page dependent? UTF8 I believe -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: barrywardell: apps/plugins/rockboy Makefile,1.15,1.16
On Fri, 29 Sep 2006, [EMAIL PROTECTED] wrote: +ifeq ($(UNAME), Darwin) +SHARED_FLAG=-dynamiclib -Wl,-single_module +else +SHARED_FLAG=-shared +endif Barry, since this is done in numerous Makefiles now, wouldn't it be nicer to have the configure script create the SHARED_FLAG variable in the root Makefile and have all other Makefiles just use that? -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Mailing lists digest mode (still) broken
Hi If you are subscribed to the rockbox or the rockbox-dev list using the 'digest' mode, you don't get any mails from the lists nowadays since this feature is currently broken. Yes, funnily enough you will of course not get this mail either, but at least it'll be in the mail archives in case you actually try to find out what the problem is with your Rockbox mails! We intend to fix the problem but as of yet we don't know why it broke and we haven't yet had time to investigate or to attempt any fixes. Please bear with us. Consider switching to non-digest mode for now if you really want to follow the lists. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Samsung YH-820 based on PP5020
On Fri, 6 Oct 2006, Anant wrote: I would like to use the RockBox firmware on my Samsung YH-820. It is based on the PortalPlayer chipset 5020 (same as iPod Mini). I do not mind porting or developing but I do not know how to get started. I have used the mi4code to decode the mi4 firmware upgrade, but do not know how to get RockBox ported to this player. 1. Read the NewPort wiki page - it having a PP5020 is just one little piece that is known, there are still lots of more you need to figure out. 2. Try the tatung bootloader from Rockbox CVS -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Recent Sansa developments
Hi While I'm not doing much Rockbox hacking lately myself, I thought I'd at least provide some updates from the Sansa e200 front. MrH is again proving to be a king amongst hackers and based on his research Dan Ankers has been able to write a working LCD driver, hopefully soon appearing in CVS. MrH has also provided info on his adventures in button and NAND flash land[*], so with a little bit of luck and more time and effort from eager hackers, we might have a growing Rockbox port soon. The Sansa work is mostly discussed here: http://forums.rockbox.org/index.php?topic=3225.0 [*] = available from here: http://daniel.haxx.se/sansa/e200.html -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
