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/
ipod 3g (was: Re: dave: firmware crt0.S,1.73,1.74)
Daniel Stenberg wrote: 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? I think so. But sadly (due to the broken cache in the PP5002s which means they run at about half the speed of the PP5020), our codecs are working too slowly. According to Daniel: iPod 3g status (using the latest CVS with no changes): mp3s play with buffer underruns. Wavs play correctly. Flac files may cause crashes, or it may just be the one I tested. I would expect FLAC playback to work in realtime, but I haven't had chance to find out more information about Daniel's crashes. 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. Thanks, Dave.
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/
Feature freeze is lifted
Hi all. It is with mixed emotions I hereby announce that the feature freeze for 3.0 is now lifted -- without 3.0 having been released. We have been in freeze for over three months now. And we have indeed fixed many bugs, but we still have critical problems that prevent a 3.0 release. With summer in full swing and many core developers away on well-deserved holidays, it is impropable that these problems will be fixed before august, which would mean four months of freeze. A third of a year. That's not fun. I, Linus and Daniel discussed the freeze over lunch today and decided that in this difficult situation, we need to focus on the core values: Rockbox is about having fun. Being in freeze with no clear end in sight is a drain on morale and enthusiasm, which is not how we want Rockbox to feel. So we decided to end the freeze now and unlock the doors to creativity and programming joy. At best, we'll get lots of new improvements and exciting features without much negative impact. At worst, the changes will destabilize the code base severely and push the prospect of a 3.0 release even further into the future than today. In order to hedge our bets, we have set a tag in CVS which we can return to and branch from if we later fix the critical bugs and would like to release Rockbox in today's state. We still think the freeze was the right decision. We just weren't able to reach the state we wanted to, in the time we wanted to. And rather than stubbornly repeating we freeze until release, we adapt to the current reality and unfreeze. Gentlemen, start your compilers. -- Björn
Re: Feature freeze is lifted
I'm in full support of this decision. When feature freeze wasn't in effect there were a lot of really interesting and cool new things being added, and honestly, the most interesting thing that's happened in the CVS logs in the past week has been some kind of solitaire bugfix (I play solitaire a LOT). I hope the featurefreeze lifting doesn't cause too much trouble in the way of the 3.0 release, I'm looking forward to it, even if it is only the speech parts of the OS that are being fixed - a feature that I personally rarely use - having 3.0 I'm sure will give me a nice fuzzy feeling.Viva la rockbox! On 7/18/06, Björn Stenberg [EMAIL PROTECTED] wrote:Hi all.It is with mixed emotions I hereby announce that the feature freeze for 3.0 is now lifted -- without 3.0 having been released.We have been in freeze for over three months now. And we have indeed fixed many bugs, but we still have critical problems that prevent a 3.0 release. With summer in full swing and many core developers away on well-deserved holidays, it is impropable that these problems will be fixed before august, which would mean four months of freeze. A third of a year. That's not fun.I, Linus and Daniel discussed the freeze over lunch today and decided that in this difficult situation, we need to focus on the core values: Rockbox is about having fun. Being in freeze with no clear end in sight is a drain on morale and enthusiasm, which is not how we want Rockbox to feel. So we decided to end the freeze now and unlock the doors to creativity and programming joy. At best, we'll get lots of new improvements and exciting features without much negative impact. At worst, the changes will destabilize the code base severely and push the prospect of a 3.0 release even further into the future than today. In order to hedge our bets, we have set a tag in CVS which we can return to and branch from if we later fix the critical bugs and would like to release Rockbox in today's state. We still think the freeze was the right decision. We just weren't able to reach the state we wanted to, in the time we wanted to. And rather than stubbornly repeating we freeze until release, we adapt to the current reality and unfreeze. Gentlemen, start your compilers.--Björn
Re: [Bulk] Feature freeze is lifted
That's a great news. Bernych Björn Stenberg wrote: Hi all. It is with mixed emotions I hereby announce that the feature freeze for 3.0 is now lifted -- without 3.0 having been released. We have been in freeze for over three months now. And we have indeed fixed many bugs, but we still have critical problems that prevent a 3.0 release. With summer in full swing and many core developers away on well-deserved holidays, it is impropable that these problems will be fixed before august, which would mean four months of freeze. A third of a year. That's not fun. I, Linus and Daniel discussed the freeze over lunch today and decided that in this difficult situation, we need to focus on the core values: Rockbox is about having fun. Being in freeze with no clear end in sight is a drain on morale and enthusiasm, which is not how we want Rockbox to feel. So we decided to end the freeze now and unlock the doors to creativity and programming joy. At best, we'll get lots of new improvements and exciting features without much negative impact. At worst, the changes will destabilize the code base severely and push the prospect of a 3.0 release even further into the future than today. In order to hedge our bets, we have set a tag in CVS which we can return to and branch from if we later fix the critical bugs and would like to release Rockbox in today's state. We still think the freeze was the right decision. We just weren't able to reach the state we wanted to, in the time we wanted to. And rather than stubbornly repeating we freeze until release, we adapt to the current reality and unfreeze. Gentlemen, start your compilers.
Re: half-idea for #ifdef and key deifnition hell...
well, now the freeze has thawed (hoho someone shoot me :p ) can we get some discussion on this happening? I reckon the button #define hell should be one of the first things tackled.? On 29/05/06, Fredrik Öhrn [EMAIL PROTECTED] wrote: Jonathan Gordon wrote: ?? first the switch/if..ifelse is just a matter of style.. and the switch uses 1 less variable.. but it really makes no diff... which for loop are u talking about? Sorry, I meant while-loop, the one inside read_button() that loops over the items array. as for checking for long/short/dbl clicks in the actual button driver.. how does it know to wait for a double click instead of diong 2 single clicks? or wait for a long press?? It doesn't, the driver will generate a key down event and then a double click event soon after, same thing for long press, a key down + long press event. It's they way it has to be or all key events would have to be delayed the amount of time it takes to detect a double click or long press. This would make the UI seem sluggish. All other OSes I know generates 2 events and it's not a problem. doing it this way enables u to use the old crappy _PRE moethd and #define all your keys.. or use this and have 1 swithc for your button loop which is neater, cleaner and easier to maintain.. Well, the current _PRE handling code could be removed completley if the button driver returns (BUTTON_xxx | BUTTON_REL) when a short press ends and (BUTTON_xxx | BUTTON_REL | BUTTON_REPEAT) for a long press. An application can then easily implement 2 different actions without having to track the previous event. /Fredrik
