Archos Ondio Backlight MOD rockbox
Hello, all I read http://www.rockbox.org/twiki/bin/view/Main/OndioBacklight And here's my question: Does rockbox actually can handle the backlight pin on the ondios? So is i worth for us to do the modification? Jörg H., do you run rockbox with light on your modded ondio? Joerch __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130
Re: Archos Ondio Backlight MOD rockbox
On 30.05.2006, [EMAIL PROTECTED] wrote: Hello, all I read http://www.rockbox.org/twiki/bin/view/Main/OndioBacklight And here's my question: Does rockbox actually can handle the backlight pin on the ondios? So is i worth for us to do the modification? Jörg H., do you run rockbox with light on your modded ondio? Joerch It can. If you roll your own build, you need to add one line to config-ondiofm.h or config-ondiosp.h, depending on your Ondio model: #define CONFIG_BACKLIGHT BL_PA14_HI (thoughts) Perhaps we should add that line to cvs, wrapped in an ifdef similar to the alarm mod? Regards, Jens
Re: Release policy and coordination
(I must say the code lacks some comments, sometimes ;). At the moment, I'm just looking round the sources trying to understand them. Would it be useful for people like myself to submit comment patches? As I look round the code, I could add comments when I work out what something does, and submit a patch with my comments in them. Malcolm. ___ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
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/
Re: Release policy and coordination
Bryn Smith wrote: Unfortunately most of the code I looked at had very little commenting. I was a little surprised to find that even functions weren't documented as to their purpose and none of the files even had a basic description of their function! Welcome to the world of unpaid volunteer work. :-) Hopefully, you will discover that lots of the code is fairly easy to understand even without comments. 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. Perhaps not. Feel free to add comments along the way and submit a patch or two. Linus
Re: Archos Ondio Backlight MOD rockbox
On 5/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think I do not need backlight anymore... Do not run (rolo) this archos stuff on your ondio box if you are running rockbox. Archos Firmware 1.32b It includes a flasher without any sanity checks and without any questions. It maked mine ready for the undertaker while loading the original archos firmware... Hi, you mean you bricked it ? It happened with my first Ondio as well. I've been recommended to flash it with rockbox as soon as possible. ~lImbus
Iaudio X5 surgery - help
Hi list, Today I tried to enable REAL_LED on the X5L by editing firmware/drivers/led.c and adding the needed pcf50606_write() to led() and changing LED_CONFIG #define in firmware/export/config-iaudiox5.h The effects of this were: 1. the red led lit up on boot 2. RB hanged at the boot screen 3. After shutting down, the device wouldn't respond anymore 4. The poor DAP terribly heated up. Yes, I tried inserting a pin to the reset hole. I ended up cooling it with ice, opening the cover and (accidentally) disconnecting the battery wire. At least it stopped warming. I'll be soldering it later, but I'd be delighted to hear your comments. R. P.S. Did you know? X5L battery is actually made of two separate batteries connected with an extension cable. The 2nd battery is taped on the back of the HDD.
Re: Iaudio X5 surgery - help
On 5/30/06, RaeNye [EMAIL PROTECTED] wrote: I'll be soldering it later, but I'd be delighted to hear your comments. Did you see anything burned/damaged ? IMHO, if it continued to heat after a reset, it's because something has gone wild (=damaged) before the reset. Reconnecting the battery will have the same effect as after the reset, it will probably restart to reheat. ~lImbus
RE: Iaudio X5 surgery - help
No, prolly thanks to the ice; I hope the HDD didn't suffer much (as it's adjacent to the bigger battery). I believe the PCF50606 went berserk, but upon disconnecting it will reset (when battery is connected the pcf never shuts down, it just stands by). I'll watch it closely, though. BTW, I tried to boot it from AC power, but to no avail. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel Dejonghe Sent: Tuesday, May 30, 2006 6:10 PM To: Rockbox development Subject: Re: Iaudio X5 surgery - help On 5/30/06, RaeNye [EMAIL PROTECTED] wrote: I'll be soldering it later, but I'd be delighted to hear your comments. Did you see anything burned/damaged ? IMHO, if it continued to heat after a reset, it's because something has gone wild (=damaged) before the reset. Reconnecting the battery will have the same effect as after the reset, it will probably restart to reheat. ~lImbus
Re: Archos Ondio Backlight MOD rockbox
On 30.05.2006, [EMAIL PROTECTED] wrote: Archos Firmware 1.32b It includes a flasher without any sanity checks and without any questions. It maked mine ready for the undertaker while loading the original archos firmware... Check the wiki; it should be possible to salvage the unit with the uart boot mod. Regards, Jens
RE: Iaudio X5 surgery - help
Good news - I connected the battery wire and it boots OK. I still have some screws to tighten, but it'll prolly survive. Just don't try this at home. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RaeNye Sent: Tuesday, May 30, 2006 7:19 PM To: 'Rockbox development' Subject: RE: Iaudio X5 surgery - help No, prolly thanks to the ice; I hope the HDD didn't suffer much (as it's adjacent to the bigger battery). I believe the PCF50606 went berserk, but upon disconnecting it will reset (when battery is connected the pcf never shuts down, it just stands by). I'll watch it closely, though. BTW, I tried to boot it from AC power, but to no avail. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel Dejonghe Sent: Tuesday, May 30, 2006 6:10 PM To: Rockbox development Subject: Re: Iaudio X5 surgery - help On 5/30/06, RaeNye [EMAIL PROTECTED] wrote: I'll be soldering it later, but I'd be delighted to hear your comments. Did you see anything burned/damaged ? IMHO, if it continued to heat after a reset, it's because something has gone wild (=damaged) before the reset. Reconnecting the battery will have the same effect as after the reset, it will probably restart to reheat. ~lImbus
Re: Release policy and coordination
Well, I think I'll toss my two cents in... There have been a few occasions where I simply head to the Flyspray bug reports page, pick out one that's rather simple, fix, and commit it. I'm quite the opposite of a 'core dev' - I hardly know enough to fix half the bugs on the tracker (especially the playback ones). Having said that, I'd quite like to fix smaller things more often. The problem for me is mostly involving the tracker. There are some duplicate and irrelevant reports, as well as rather ambiguous ones, and reports for the same build/model I'm using but I'm not able to reproduce it, even if steps are provided. For example, we get a lot of 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; we/I can't really close it because we don't know if it's fixed, but that's just another one sitting in the list as a 'bug' that probably is no longer. I'd really *like* to clean up the bug reports page, and every time I try to do it I give up because I just don't know what should be done with them. Clearer guidelines for that would help, IMO. Also, I second that the ReleaseTodo should be more specific - I think for 3.1 we should try to be a bit more firm about this. We should be more specific and descriptive about what exactly needs to be done, and what should be done, and keep it up to date (other than my attempted update at the ReleaseTodo page a week or so ago, for example, the percentages toward the listed goals hadn't changed in probably a month). Keeping things up-to-date and clear about todo stuff should help a lot for 3.1, I think. A 'release coordinator' would help a lot, too. I know I'm responsible for a lot of the non-bugfix commits. I probably shouldn't have commit access in any case, but I won't complain. :) I simply find that features/updates are usually easier and more enjoyable for me to code - writing new stuff in my own style is preferable to fixing bugs that could be anywhere in someone else's style. Next feature freeze, however, I'll definitely do more bugfixing, and less of the more unimportant stuff. On 5/30/06, Christi Alice Scarborough [EMAIL PROTECTED] wrote: I'm afraid that despite offering to shepherd this release through, I haven't been able to follow through on that for the usual reason (poor health). My regrets that that's left a void, but it's been unavoidable I'm afraid. Daniel Stenberg wrote: A) drop H300 from the release and ship Rockbox 3.0 for Archos and iriver H100 on friday. I'd have to say that I'm loathe to come out of freeze until the core functionality is actually bug free. A lot of the difficulty with current Rockbox development is that while there are many people working on bells and whistles, not enough coders are working on making sure the darn thing actually plays music reliably. There has been some lovely work on plugins and the UI, but it's all a bit pointless if it doesn't work. 3.0 is more than a release. It's a stamp of approval and a mark of quality. Having said that, we can't stay in freeze forever, but if we don't have a release quality product, there's little point in coming out of freeze. The moment we come out of freeze, a whole slew of new features will go into the source, and a slew of new bugs with them. If the current code is flaky, how much more flaky will post 3.0 code be? One of the really strong features of the Rockbox 2.x series has been that it's been stable for a long long time. Releasing 3.0 as a step back in stability would be a big disappointment. Having said that, I'm really not sure how to fix the issue of the fact that there's not enough knowledgeable people working on the code. I'm as guilty of this as the next coder - I'm the first to admit that the playback engine is voodoo to me - but I can't see myself having the time to devote to understanding it properly in the near term. The bottom line: if we want to release Rockbox, we need more coders willing and able to get to grips with both the firmware layer and the playback engine. Christi -- - Zakk [EMAIL PROTECTED]
Re: Release policy and coordination
Ah, but the battery life issue on H300 is an actual major bug, most likely, rather than simply our software running less efficiently than it could. At least, that seems to be the current belief. So instead of an improvement, it's a real bug. People can still download the 3.0 source and compile for H300, but I don't feel that we can in good conscience say that it's working as it should, which we should be able to with a release.On 5/30/06, Jonathan Gordon [EMAIL PROTECTED] wrote: im in the same boat as midkay.. i wouldnt mind fixing bugs if iactually could.. but most of the code is over my head..also, apart from a fwe playback issues i tinhk the current cvs isfarily stable.. and battery life shouldnt be a reason to not release for h300 (not that it really means anything to most of the pplwatching this list..)On 31/05/06, Zakk Roberts [EMAIL PROTECTED] wrote: Well, I think I'll toss my two cents in... There have been a few occasions where I simply head to the Flyspray bug reports page, pick out one that's rather simple, fix, and commit it. I'm quite the opposite of a 'core dev' - I hardly know enough to fix half the bugs on the tracker (especially the playback ones). Having said that, I'd quite like to fix smaller things more often. The problem for me is mostly involving the tracker. There are some duplicate and irrelevant reports, as well as rather ambiguous ones, and reports for the same build/model I'm using but I'm not able to reproduce it, even if steps are provided. For example, we get a lot of 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; we/I can't really close it because we don't know if it's fixed, but that's just another one sitting in the list as a 'bug' that probably is no longer. I'd really *like* to clean up the bug reports page, and every time I try to do it I give up because I just don't know what should be done with them. Clearer guidelines for that would help, IMO. Also, I second that the ReleaseTodo should be more specific - I think for 3.1 we should try to be a bit more firm about this. We should be more specific and descriptive about what exactly needs to be done, and what should be done, and keep it up to date (other than my attempted update at the ReleaseTodo page a week or so ago, for example, the percentages toward the listed goals hadn't changed in probably a month). Keeping things up-to-date and clear about todo stuff should help a lot for 3.1, I think. A 'release coordinator' would help a lot, too. I know I'm responsible for a lot of the non-bugfix commits. I probably shouldn't have commit access in any case, but I won't complain. :) I simply find that features/updates are usually easier and more enjoyable for me to code - writing new stuff in my own style is preferable to fixing bugs that could be anywhere in someone else's style. Next feature freeze, however, I'll definitely do more bugfixing, and less of the more unimportant stuff. On 5/30/06, Christi Alice Scarborough [EMAIL PROTECTED] wrote: I'm afraid that despite offering to shepherd this release through, I haven't been able to follow through on that for the usual reason (poor health).My regrets that that's left a void, but it's been unavoidable I'm afraid. Daniel Stenberg wrote: A) drop H300 from the release and ship Rockbox 3.0 for Archos and iriver H100 on friday. I'd have to say that I'm loathe to come out of freeze until the core functionality is actually bug free.A lot of the difficulty with current Rockbox development is that while there are many people working on bells and whistles, not enough coders are working on making sure the darn thing actually plays music reliably.There has been some lovely work on plugins and the UI, but it's all a bit pointless if it doesn't work.3.0 is more than a release.It's a stamp of approval and a mark of quality. Having said that, we can't stay in freeze forever, but if we don't have a release quality product, there's little point in coming out of freeze. The moment we come out of freeze, a whole slew of new features will go into the source, and a slew of new bugs with them.If the current code is flaky, how much more flaky will post 3.0 code be? One of the really strong features of the Rockbox 2.x series has been that it's been stable for a long long time.Releasing 3.0 as a step back in stability would be a big disappointment. Having said that, I'm really not sure how to fix the issue of the fact that there's not enough knowledgeable people working on the code.I'm as guilty of this as the next coder - I'm the first to admit that the playback engine is voodoo to me - but I can't see myself having the time to devote to understanding it properly in
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: bug report closing (was Re: Release policy and coordination)
I agree, with the ability of anyone to close bug reports, you should be able to close them with a message like This should be fixed in CVS now. Open a new one if the bug still exists, with updated instructions on how to reproduce them with a new build. On 5/31/06, Daniel Stenberg [EMAIL PROTECTED] wrote: 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 nobodyreplies 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/
