mpf70-devel Mailing List for MPman MP-F70
Status: Inactive
Brought to you by:
jeremy_laine
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Jeremy <jer...@po...> - 2004-09-19 10:36:52
|
Hello all! First of all, thanks for your interest in the MPF70 support for linux. I am currently starting a new job and don't think I can put significant time into porting the driver to 2.6. Adrian Reber has started some work in that direction, it would be interesting to pick up from there. Adrian, can you send me your latest patch against CVS please? For those of you interested in doing some work on the driver, email me and we'll discuss CVS commit access. I hope to get back to working on the module myself in a couple of months but in the meantime it would be great to get things rolling! Regards, Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: <ben...@id...> - 2004-05-22 12:04:59
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Jeremy <jer...@po...> - 2004-05-01 15:52:41
|
Welcome aboard Adrian! I have added you as a developer for the mpf70 project, so it is now possible for you to commit both on the "mpf70" and "mpf70-utils" modules. If you don't mind, I'd rather you only commit on the utils for the moment, as I haven't had a chance to look through your 2.6 kernel code yet. Let me know if you run into any difficulties! Cheers, Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Adrian R. <ad...@li...> - 2004-05-01 14:53:30
|
On Sat, May 01, 2004 at 04:29:41PM +0200, Jeremy Lain=E9 wrote: > > http://lisas.de/~adrian/gtkmpf70/gtkmpf70-0.2.tar.gz >=20 > I have commited your code into the mpf70-utils CVS repository, with > your Gtk specific code in src/gtk. I have (hopefully) made the > necessary adjustments to the build scripts. You will want to run > configure with the "--enable-gtk" switch. I will try it out. > > It requires gtk-2.4. >=20 > Why 2.4? As I am not really familiar with Gtk, I don't know the > differences between versions. What I do know is that I can't currently > install gtk-2.4 under Debian so I cannot test your program. It is in experimental. I also use debian so it should be no problem. The only reason why it requires 2.4 is because i am using the new file dialog. This is really not necessary, but as it was new and as I already used it in another application... I just liked it. > Can you possibly give me your sourceforge login so that I can give > your commit access to the CVS repository? I have no sf.net account, but I will look how and where to get one. Adrian --=20 Adrian Reber <ad...@li...> http://lisas.de/~adrian/ No one can guarantee the actions of another. -- Spock, "Day of the Dove", stardate unknown |
From: Jeremy <jer...@po...> - 2004-05-01 14:29:58
|
Hi Adrian, > http://lisas.de/~adrian/gtkmpf70/gtkmpf70-0.2.tar.gz I have commited your code into the mpf70-utils CVS repository, with your Gtk specific code in src/gtk. I have (hopefully) made the necessary adjustments to the build scripts. You will want to run configure with the "--enable-gtk" switch. > It requires gtk-2.4. Why 2.4? As I am not really familiar with Gtk, I don't know the differences between versions. What I do know is that I can't currently install gtk-2.4 under Debian so I cannot test your program. Can you possibly give me your sourceforge login so that I can give your commit access to the CVS repository? Cheers! Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Adrian R. <ad...@li...> - 2004-04-29 08:38:06
|
On Wed, Apr 28, 2004 at 11:22:02PM +0200, Jeremy Lain=E9 wrote: > I have had quite a lot of work to do so far this week and will be > travelling tomorrow, I'm still hoping to import your GUI code before > the week is out! No problem. I know how it can be. The main part of my GUI code was written over a year ago and I never had the time to finish it to be release ready. So no need to hurry now :-) Adrian --=20 Adrian Reber <ad...@li...> http://lisas.de/~adrian/ The Roman Rule: The one who says it cannot be done should never interrupt the one who is doing it. |
From: Jeremy <jer...@po...> - 2004-04-28 21:22:10
|
> Do you have any documentation of the hardware because the only thing > I have is your source :-) Unfortunately not! Mpman didn't give me any information at all so I had to reverse-engineer the whole darn thing using a USB sniffer and some imagination.. I have had quite a lot of work to do so far this week and will be travelling tomorrow, I'm still hoping to import your GUI code before the week is out! Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Adrian R. <ad...@fh...> - 2004-04-28 19:49:13
|
On Mon, Apr 26, 2004 at 10:05:43AM +0200, Jeremy Lain=E9 wrote: > Cool, for the GUI, I'll have a look at it. I had taken care to separate > MPF70 operations from the Qt-specific stuff, did you make use of the > existing library? If so, it should be quite easy to add your source to > the CVS repository. Yes I did use your library to access the device. > In the very near future, I am more interested in the work you did on th= e > 2.6 kernel, as it's something I've been meaning to do but never got > round to! I took a look at how the USB & block device drivers had > changed since 2.4 and there seemed to be a lot.. Some information about my 2.6 driver. As I already mentioned the driver is still _very_ buggy. The first thing I have done during porting the driver was to change block device stuff and I thing I have done it pretty well. The next step was to port the usb related part. In the beginning it seemed that this would not be very difficult and I quickly had a version which compiled, loaded ans supported mounting the device. But during mounting the kernel keeps printing call traces because the driver does somehow call schedule although we are atomic. After reading source code and mailinglists I think I do know now what the problem is. During the mount operation we aren't any more in the process context but in interrupt context and this is an atomic situation. The usb call I am currently using (usb_bulk_msg()) does however call schedule() somewhere. To avoid this situation I have to use usb_submit_urb() because this call is not synchronous. I tired using usb_submit_urb() but was not able to communicate with the player but I am still trying to get this working. Do you have any documentation of the hardware because the only thing I have is your source :-) Adrian --=20 Adrian Reber <ad...@li...> http://lisas.de/~adrian/ intoxicated, adj.: When you feel sophisticated without being able to pronounce it. |
From: Jeremy <jer...@po...> - 2004-04-26 08:03:35
|
Hi Adrian! Cool, for the GUI, I'll have a look at it. I had taken care to separate MPF70 operations from the Qt-specific stuff, did you make use of the existing library? If so, it should be quite easy to add your source to the CVS repository. In the very near future, I am more interested in the work you did on the 2.6 kernel, as it's something I've been meaning to do but never got round to! I took a look at how the USB & block device drivers had changed since 2.4 and there seemed to be a lot.. Can't promise to look at your code tonight but it should get done sometime this week! Once it all looks OK would you like to join the project so you can commit directly? Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Adrian R. <ad...@li...> - 2004-04-22 19:33:37
|
Hi, i have written a simple gtk based gui for the mpf70 mp3player. It does pretty much the same as the qt version. http://lisas.de/~adrian/gtkmpf70/gtkmpf70-0.2.tar.gz It requires gtk-2.4. Another thing I tried is porting the kernel driver to 2.6 The result can be found at http://lisas.de/~adrian/gtkmpf70/mpf70-2.6.tar.gz To compile the driver you have to execute following command: make -C /path/to/kernel/sources/linux-2.6.3 SUBDIRS=$PWD modules I can mount the mp3 player and read/write, but it is far from being usable. The kernel keeps printing call traces because there is a "bad: scheduling while atomic!" One should be careful because I had to reformat the player after testing the module. As I do not have many usb driver experience I am currently at a point where I don't know what to do. So maybe someone else has a good idea. Adrian -- Adrian Reber <ad...@li...> http://lisas.de/~adrian/ Zoidberg: "Hooray, I'm useful. I'm having a wonderful time." |
From: J. V. <jvo...@gm...> - 2004-01-26 04:40:49
|
Just a test, ignore it. Didn't recieve confirmation of subscription, so this seems nessessary. Thx, mfG Johannes |
From: Jeremy <jer...@po...> - 2003-12-10 11:18:35
|
Hi Anthony! Indeed, I wrote the library some time ago to keep the frontends separated from the core operations. The command-line and Qt versions therefore use the same operations. I think the best is that you just create a "gtk" subdirectory, like the current "qt" subdir. You can customise the configure.ac to add an --enable-gtk switch! We'll just keep the library as a convenience library for the moment, as the are no known "outside" projects based on the library, the chances are really minor to turn it into a self-standing lib. I am going to be fairly busy until end of January as I have to sort out my removal back to France, but I'll try to answer any questions you might have as they arrive :) If you feel that some things could be improved in the library itself, tell me, but try to have a look what impact they will have on the command-line and Qt frontends. If you want, I'll handle the alterations to debian/* once you have a binary that compiles to make sure your GUI gets packaged OK. Finally, don't forget the output for the code documentation of the mpf70-utils is available here: http://dev.jerryweb.org/doxygen/mpf70-utils/ Giving the GUI a refresher is an excellent idea, the current one is somewhat sketchy! In time, we can probably drop the Qt version altogether and focus on your new one. Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Anthony H. <ant...@un...> - 2003-12-10 09:27:27
|
Hello Jeremy ! i'm back :P i discovered you've now create a library to manage "core" operations (playlist, fonts ...) on the mpf70 folder ! that's great ! i'd like to work on a gtk (may be "gnome-ized") application to use the mpf70. Do you know it's possible for you to create a new "package" libmpf70.tar.gz, and totally separate your qt application and the library ? Or do i prefer i work in a "gtk" subdirectory on mpf70-utils package ? See you ! Anthony |
From: Jeremy <jer...@po...> - 2003-11-09 23:12:08
|
Hi! Anthony, what was the trick to get the module to work without devfs? Anyhow, the code does not need editing, Anthony already made sure it worked :) Cheers, Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux > > Hi > > I tried to use the mpf70 kernwel module but I'm running into a > problem cause I do not use the devfs system. > > So I tried to assign a fixed major device number in the source code > and made the device file by hand (mknod). But this also failed. > > Can you give a hint what to do to get the module running without > devfs? > > thanks > Uli |
From: Kiss K. <cr...@kl...> - 2003-10-19 10:08:05
|
Hello, Hmmmm .... You have a point. Still I don't see how this didn't work for me. I tryed something similar with a list of 8 devices and I had the simptoms you describe. After 8 connects and disconnects the driver didn't accept new devices. I see why I saw that the pointer contains an integer with the address of the device, though ... The usb_device structure has this integer as it's first element. So I have to admit it was a false alarm :o((( Regards Kiss Karoly On Sun, 19 Oct 2003, Jeremy [ISO-8859-1] Lain=E9 wrote: > Hi! > > I'm not sure what you describe is accurate, there would already be > problems in a single device situation upon disconnecting/reconnecting. > If you look at mpf70.h you'll see that currently, the "list of > devices" only allows for one device (MPF70_MAX =3D 1). If indeed I am > writing s->usbdev =3D NULL in the wrong place, reconnecting the device > work should cause a failure (mpf70_find_struct would not find an entry > with a NULL usbdev). This is not the observed behaviour! > > Jeremy > |
From: Jeremy <jer...@po...> - 2003-10-18 22:21:57
|
Hi! I'm not sure what you describe is accurate, there would already be problems in a single device situation upon disconnecting/reconnecting. If you look at mpf70.h you'll see that currently, the "list of devices" only allows for one device (MPF70_MAX =3D 1). If indeed I am writing s->usbdev =3D NULL in the wrong place, reconnecting the device work should cause a failure (mpf70_find_struct would not find an entry with a NULL usbdev). This is not the observed behaviour! Jeremy -- =20 http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux On Sat, 18 Oct 2003 15:59:32 +0200 (CEST) Kiss Karoly wrote: > Hello, >=20 > The mailing list is OK with me. I just subscribed to it. > In my e-mail what I meant was that it's ok that you try to set the > s->usbdev =3D NULL; > but that never happens because you are in the wrong place in memory. > So if later you try to view what devices you have attached in your > static block of devices one of your pointers will not be NULL ( > which you intended it to be ) and you would violate the rule you > described to me in your letter earlyer. >=20 > > "After returning from the disconnect function the USB framework > > completly deallocates all data structures associated with this > > device. So especially the usb_device structure must not be used > > any longer by the usb driver." >=20 > This means that you still have a pointer to the usb_device structure > in your list of devices. >=20 > Regards > Kiss Karoly >=20 > On Sat, 18 Oct 2003, Jeremy [ISO-8859-1] Lain=E9 wrote: >=20 > > Hello Anthony, > > > > Kiss Karoly (cc of this email) has been looking throught the mpf70 > > driver code as he is interested in producing a kernel module for > > the mpf50. I thought maybe you'd be interested in joining the > > discussion:) > > > > If it's ok with both of you maybe we can switch to : > > mpf...@li... > > > > .. so there is a trace of all this! > > > > Regards, > > Jeremy > > > > -- > > http://www.jerryweb.org/ : JerryWeb.org > > http://sailcut.sourceforge.net/ : Sailcut CAD > > http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux > > > > --- > > Date: Sat, 18 Oct 2003 12:15:10 +0200 (CEST) > > From: Kiss Karoly > > To: Jeremy Lain=E9 > > Subject: MpMan driver > > > > > > Hello Jeremy, > > > > I noticed a little bug in your mpf70 driver, it's probably not a > > big thing > > but anyways I think you should know. > > In your mpf70_disconnect function you typecast the void *ptr to > > mpf70_t > > type and set the usbdev in it to NULL. That is wrong because that > > pointer > > contains a pointer to an integer containing the address of the usb > > device > > on the bus. > > It probably does nothing important but if you try to handle more > > than one > > device with your driver you will notice that it does not free the > > appropriate resource. Not to mention that you could write a NULL > > value somewhere you shouldn't. > > > > Regards > > Kiss Karoly > > |
From: Jeremy <jer...@m4...> - 2003-03-10 19:57:03
|
The mpf70 kernel module has a cache whose size is a multiple (MPF70_CACHE = 2 at present) of MPF70_BLOCK (=32) sectors. The reason for this cache is that the internal memory of the player is a flash device and whenever a write operation is requested to one or more sectors, the full corresponding block first gets erased! I had originally tried to set the block device's physical sector size to match the block size, but this value is too large and the kernel refuses it. Anyway, as the filesystem is FAT, the block device has to support 512 byte writes. Alan Cox was the one who suggested a buffer mechanism in response to a message I posted on the Linux kernel mailing list. The idea of the cache is that as we buffer sector write requests to the player until the sector we are asked to write is outside of the cache. A map of the sectors in the cache is maintained, so that when it is time to flush the cache, we know if any sectors need to be read off the player before we actually start writing. In practice, when writing files to the player we always write full blocks (except the very last sectors of the file) so no reading is required. Updating the FAT is a different story, as we only get a request to write a single 512 byte sector so here we do have to read the missing sectors from the player before the write occurs. This does not really cause a big performance hit as there a very few writes to the FAT compared to actual data transfers. Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |
From: Jeremy <jer...@m4...> - 2003-03-05 16:39:35
|
I've commited some code that should handle USB timeout errors, but unfortunately I have yet to reproduce a timeout situation, so I can't be positive! One thing is for sure, disconnect situations are handled a lot more gracefully. In the old code a null pointer exception could occur as the "usbdev" pointer of the mpf70_t structure gets set to NULL on disconnect. Also, the module use count is now increased/decreased upon mount/unmount, not upon probing the device. Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/ : MPman MP-F70 support for Linux |