OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: danboid on September 11, 2006, 03:44:35 am
-
http://bugs.openembedded.org/show_bug.cgi?id=1308 (http://bugs.openembedded.org/show_bug.cgi?id=1308)
Seeing as no comments have been made alongside my bug report other than my own I would presume that nothing has been done about this yet. I've come to highlight this bug again as having the matchbox-cards-applet working and pre-installed on the next OZ/GPE image would do wonders for the useability factor, as anyone who has used this tool under pdaXrom will attest. It eliminates the need to use the commandline when dealing with cards- very important to many (potential) OZ users.
Hopefully I'm just out of the loop here and its been fixed already
-
I agree this should be installed by default.
I'm not sure of the status though. Have you tried asking on IRC?
Si
-
would do wonders for the useability factor
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141102\"][{POST_SNAPBACK}][/a][/div]
Actually, it wouldn't. I tap on the icon and I get a (incomplete) list of cards with a green button besides them. How do I know what will happen when I tap on the item? I tried to tap on the sd item, but suddenly my c700 froze. Apparently it did something bad to my root-on-sd setup. On my ipaq it doesn't show the two pcmcia slots, only one. So how is that an improvement?
It would need to get rewritten to be able to claim 'useaility'.
-
Indeed, it may also be necessary to stop users from being able to easily eject the internal HDDs.
Anyone fancy learning to do some coding? It's a pretty small program from what I remember, and all in C so easy to understand.
Si
-
replies at last!
I'm surprised how long it took to get some kind of response to this which I see as a full-on showstopper. This is a perfect example of how distanced most of the oe devs requirements and uses of a rom are from those of a normal user. Being devs they will use a terminal constantly so managing cards by a command is no big deal to them but your standard sharp/cacko Z user is much less dependant on the cli and I think most would prefer to avoid it totally if possible.
Koen:
What you say is totally true and you've raised yet another flaw of the current mb-card-applet that I forgot in my bug report- it shouldn't show the internal disk (why would you ever want to unmount that?) if present, only the status of the SD and removeable CF slot.
What I do mention in my bug report though is that the mb-card-applet under pdaxrom works just fine so why can't we use the exact same version (although I can't tell you what version that is)? I also mention that the mb-card-applet in 3.5.4.1 is a few versions behind the latest stable release, so maybe just upgrading will fix these problems?
If this app is working out of the box in the next OZ/GPE release then I can guarantee many more OZ converts, such as myself (the missing UK keymap bug would have to be fixed too though)
-
What I do mention in my bug report though is that the mb-card-applet under pdaxrom works just fine so why can't we use the exact same version (although I can't tell you what version that is)? I also mention that the mb-card-applet in 3.5.4.1 is a few versions behind the latest stable release, so maybe just upgrading will fix these problems?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=141582\")
We can't use the same one as in pdaX, since that would be piracy. The pdaX one contains copyrighted material (like the picture of the cards). The applet also isn't part of matchbox, so your claims of 'a few versions behind the latest stable' are also wrong.
The next thing that is a showstopper is the fact that the pcmcia interface it relies on will be removed in kernel 2.6.18.
To sum it up:
1) it allows people to shoot themselves in the foot
2) only users familiar with the applet know what it does, otherwise goto 1)
3) 'upstream' promotes piracy
4) wouldn't work with recent kernels
5) doesn't show the correct number of slots.
And FWIW, it has been in the feeds for a long time: [a href=\"http://ewi546.ewi.utwente.nl/tmp/hrw/fb/?action=details&pnm=matchbox-applet-cards]http://ewi546.ewi.utwente.nl/tmp/hrw/fb/?a...ox-applet-cards[/url]
-
danbold: that applet was once added because someone requested it. If you really use it then extend it with needed features or find someone who will do it for you.
Current pdaX builder contain version 1.0.3 (OZ has 1.0.2) but the only change is usage of sudo to manage cards.
-
danbold: that applet was once added because someone requested it. If you really use it then extend it with needed features or find someone who will do it for you.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141615\"][{POST_SNAPBACK}][/a][/div]
It's a modified version that removed the pirated stuff. Maybe Patrick Steiner, who did the clean-up to get it into OE, would be interested in hacking it further.
-
1) it allows people to shoot themselves in the foot
As you say, when run under OZ it shows your root drive and lets you try to unmount it. It didn't do this under pdaX so there SHOULD be no problem there.
2) only user familiar with the applet know what it does, otherwise goto 1)
That is more a problem of documentation and the distribution. I only knew such an app existed because I have also tried pdaX. For me the biggest revolution in the usability of X11 came when KDE and GNOME integrated one-click (OK, 2 normally) mounting and unmounting of discs. If they didn't do that well then I would have stuck with FVWM or whatever. OZ
BADLY
needs a tool to perform a similar function with removeable cards if it wants to stand a serious chance of replacing the crappix twins as the Z rom of choice
3) 'upstream' promotes piracy
Again, this is no problem as we could surely find some free graphics or create our own as replacements
4) wouldn't work with recent kernels
How recent? You make it sound as though it should be working with 2.6.17
5) doesn't show the correct number of slots.
Why did it work perfectly under pdaXrom? Is this due to big changes in the 2.6 pcmcia kernel interface?
I would love to help develop a replacement or try patching up this current app to get something working under OZ but unfortunately that is not an option as I don't have a Z. My dad has a c3000 but that is in France with him (as it often is) for another 5 or 6 weeks. He really wants to dump cacko for OZ so he does let me have the odd weekend to try out a new release sometimes but he needs it for his work so can't lend it me to mess with for extended periods. I'm too poor to buy a Z myself right now.
I know its not geared towards PDA use but another option could be using the Devicehandler util that has been developed for use with the ROX desktop. Have any of the OZ devs got to check this out as a potential graphical card management solution?
-
use the cardmon applet from the 3.5.4 feed which actually works for unmounting SD cards. The one in the 3.5.4.1 feed is broken!
-
Thanks for pointing that out meanie, but can cardmon also be used to eject (turn off) and turn back on my CF wifi card? That is the main reason I want a gui card manager.
If cardmon can do all this then it should be installed in the default OZ/GPE image (once they've fixed whatever bug has arisen for it in 3.5.4.1 of course)
-
Thanks for pointing that out meanie, but can cardmon also be used to eject (turn off) and turn back on my CF wifi card? That is the main reason I want a gui card manager.
If that's all you want and you don't get any joy with cardmon, then you could simply create a couple of scripts:
cardctl eject <slot # of your wifi card>
&
cardctl insert <slot # of your wifi card>
then map them to a couple of hotkeys and Bob's your uncle. I don't use any of those matchbox applets because they take up far too much precious memory.
-
use the cardmon applet from the 3.5.4 feed which actually works for unmounting SD cards. The one in the 3.5.4.1 feed is broken!
Isn't cardmon for Opie? We're talking about GPE here afaik.
That is more a problem of documentation and the distribution.
Indeed, feel free to add more docs/workarounds to http://wiki.openzaurus.org (http://wiki.openzaurus.org) (not just for this)
3) 'upstream' promotes piracy
Again, this is no problem as we could surely find some free graphics or create our own as replacements
Someone has to actually get on and do this though...
5) doesn't show the correct number of slots.
Why did it work perfectly under pdaXrom? Is this due to big changes in the 2.6 pcmcia kernel interface?
I don't think pdaX runs on the iPAQ; this may be why.
4) wouldn't work with recent kernels
How recent? You make it sound as though it should be working with 2.6.17
There's no point in putting work into something which will be out of date within a fortnight is the point I think Koen is trying to make.
Si
-
Isn't cardmon for Opie? We're talking about GPE here afaik.
Yes. we are talking about GPE/X11 here. Is cardmon an Opie app? No use to me then.
Again, this is no problem as we could surely find some free graphics or create our own as replacements. Someone has to actually get on and do this though...
Graphics are nice but far from essential. A little pop-up menu with icons (just text would be fine) displaying the device name and status would be good enough for me, as long as it worked.
I don't think pdaX runs on the iPAQ; this may be why.
Eh? Just where did the iPaq come into this? I understand GPE started life off on ipaq Linux but I don't see how this relates to an app (mb-card-applet) that I saw running perfectly well on a Zaurus version of Linux/X11 (pdaXrom). How hard could it be to get this app working, with or without graphics (a green/red 'light' would do) under recent kernels?
Desertrat has proposed a good idea but even if that idea was implemented in the standard distro it wouldn't be as obvious and user friendly as what I'm proposing here.
Next OZ/GPE release will be a killer if this gets sorted!
-
I spent half a day looking at the mb-applet-cards code and it just isnt worth rescueing.
It is nasty, hacky, buggy and works by luck more than anything else.
-
Desertrat has proposed a good idea but even if that idea was implemented in the standard distro it wouldn't be as obvious and user friendly as what I'm proposing here.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=141719\"][{POST_SNAPBACK}][/a][/div]
Actually, he didn't 'cardctl' won't be present in images that run 2.6.16+, since that's using the deprecated ioctl I was referring to.
-
OK
So it looks like mb-card-applet and using cardctl have both been struck off as viable solutions so what about using DeviceHandler
ftp://ftp.berlios.de/pub/rox4debian/apps/...ndler-0.2.8.tgz (http://ftp://ftp.berlios.de/pub/rox4debian/apps/DeviceHandler-0.2.8.tgz)
I dunno if it already has support for CF and SD cards, especially CF devices such as WiFi cards.
-
Eh? Just where did the iPaq come into this? I understand GPE started life off on ipaq Linux but I don't see how this relates to an app (mb-card-applet) that I saw running perfectly well on a Zaurus version of Linux/X11 (pdaXrom).
This is why I mentioned it:
5) doesn't show the correct number of slots.
This refers to the iPAQ sleeve. As the OpenEmbedded-derived images run on many platforms, this kind of thing is better taken account of rather than having lots of if this else that statements.
Si
-
What is 'the iPAQ sleeve'?
I'd like to hear peoples thoughts on DeviceHandler- is it going to be able to what I want? If it can't (in its current state) then how hard would it be to adapt it for use on the Z? All I want it a GUI to provide one-click unmounting of SD and CF cards (which both obviously get auto-mounted already) and one click to turn on/off my wifi card.
-
From the lack of responses to my question it would be fair to say it seems that none of the OZ devs are bothered about graphical card management, not at the moment anyway.
Am I the only one who thinks this is an important missing feature of OZ?
-
Am I the only one that thinks that some people should
a) learn how to use google
B) actually do something instead of harassing developers
?
-
I'm alright with Google- why what should I be searching for?
If I had a Z to try DeviceHandler under OZ on I would but sadly I don't- I just want to know if it would work. I can't think of a better place to ask this question.
-
Am I the only one that thinks that some people should
a) learn how to use google
B ) actually do something instead of harassing developers
?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=142228\"][{POST_SNAPBACK}][/a][/div]
+1 Flamebait.
Stupid answers for stupid questions? Try not abusing your users - especially those with valid concerns.
+1 for a new GPE card applet. I would write one with Python or somesuch but I just don't have time right now to research creating an applet for the menu system in GPE (my brain is fried from doing webdev all day, so excuse my ).
Koen, I really appreciate what you and the other devs have done with OZ, but take it easy on the users. Maybe some more cross-posting of good info between the OZ wiki and the forums? Bug reporting guidelines/tips in the wiki would be a good start. I want to report bugs (lots), but I am not going to report bugs if I get flamed by the devs for not placing it in the right bug tracker or some other nonsense. "You didn't read man 8 of $randompackage! RTFM! GCC isn't supposed to be able to compile executables out of the box! RTFM!" Your post ^ is a case in point.
Maybe a blog on the OZ page relating to what is being fixed in the bugtracker, when important packages have been updated, what is in the pipeline for developement.. oz-dev mailing list is nice, but I don't know. Something is missing. People get flamed for "stupid" questions (Why doesn't a pda distro have a card control/wifi/$randomuseful applet?) and it probably isn't healthy for the community. Maybe its because OZ may not have any active "Community Relations" people? /rant
Got Flamebait?
-
Thank you CarbonFreeze- you hit the nail on the head.
Now if someone would take 10 mins to answer my question, wow I'd be happy!
-
Now if someone would take 10 mins to answer my question, wow I'd be happy!
The chances are that no-one has looked at DeviceHandler, or at least no-one who reads the forum, and that's why you have no replies.
I'm interested in the whole card utility thing, but am pretty busy and haven't had a chance to look at what DeviceHandler does (though I have downloaded it).
You will get more exposure if you post a question of this sort on #irc, or better on the mailing list (openzaurus-devel or angstrom probably)
Some links to the above:
http://openzaurus.org/wordpress/links/ (http://openzaurus.org/wordpress/links/)
http://www.openembedded.org/contact (http://www.openembedded.org/contact) (for irc details, then try #angstrom or #openzaurus)
http://www.angstrom-distribution.org/contact (http://www.angstrom-distribution.org/contact)
Even better would be to attempt to patch the current utility (I know you don't have a Zaurus atm, but you should be able to see whether the code compiles and submit a prelim patch/new app). If you simply want to ask whether it will be considered, then you need to explain exactly what is it and what the advantages of using it will be.
I want to report bugs (lots), but I am not going to report bugs if I get flamed by the devs for not placing it in the right bug tracker or some other nonsense. "You didn't read man 8 of $randompackage! RTFM! GCC isn't supposed to be able to compile executables out of the box! RTFM!" Your post ^ is a case in point.
Well report away, the only real guidelines are the usual ones: check that the bug isn't already present, and provide as much info/test cases/etc. as possible.
If your bug does exist, it will simply be closed. IMHO, it's better to have some bugs with too little data, than no-one willing to add bugs as they are worried about being told off. The other option is to come on #openzaurus and ask whether anyone knows about said bugs, and if not, add the bugs.
Si
-
Thanks Lardman for the clarification.
-
hi,
i did a quick look at ftp://ftp.berlios.de/pub/rox4debian/apps/...ndler-0.2.9.tgz (http://ftp://ftp.berlios.de/pub/rox4debian/apps/DeviceHandler-0.2.9.tgz)
but there are some problems with this app
is written in python:
you need python-libs to run it on your device
python is not really fast
needs hal:
you have to install hal on you device
needs lib-rox:
blows up gpe-image again
i currently setup my Zaurus and after that i´ll take a look at the current matchbox-applet-cards.
btw. i have build the oz-mb-applet-cards patch and replaced the icons in OE
law
-
Let me paste the mail I sent to the OZ-devel list about this.
********* *BEGIN ENCRYPTED or SIGNED PART* *********
[too lazy to do correct bottom posting]
it would be cleaner and easier to write an applet from scratch for the new kernel 2.6
infrastructure, since 2.4 is dead, buried and obsolete.
The applet basically has to do:
* check is pcmcia and/or sd is present, otherwise present a error-dialog
* open /proc/cpuinfo to find out which device it's running on and hide unused slots (port
1 on c7x0 for example, but not MD on cxxx).
* parse /proc/mounts
* work out the blacklist based on machine and where the rootfs is mounted
Instead of using coloured bullets it should display an 'eject' pictogram so people not
familiar with the applet will know it will eject it.
regards,
Koen
Patrick Steiner schreef:
> > Ok,
> >
> > i´ll setup a current openzaurus-devel repository and build an oz-dev
> > image, after that i´ll help you.
> >
> > this will take some time... :-)
> >
> > patrick
> >
> > Nicolas FR wrote:
>> >> Yes of course I have looked at your patch,
>> >>
>> >> But a few problems are araising:
>> >>
>> >> - the cardctl command is hardcoded in the program. Depending weither
>> >> you are using cardctl or pccardctl makes the program crashing.
>> >>
>> >> - depending on the distro /var/run/stab is not used (so the parsing
>> >> has to be done with the output of pccardctl or cardctl)
>> >>
>> >> - When using udev the SD mount point is not /media/card but is
>> >> attributed automatically by udev under /media/devicename
>> >>
>> >> - On Zaurus spitz the CF slot is 1 (not 0 which is the internal CF slot!)
>> >>
>> >> That's why I am suggesting to use a .conf file for the applet, that
>> >> would solve all this problems.
>> >>
>> >> I have manager to tweak the patch to make it run, but it's very bad.
>> >> And I don't even know how to parse a string in C to make a good fix.
>> >>
>> >> Would you help me on that? I can explain exactly what to do and how,
>> >> but can't implement it.
>> >>
>> >> Nicolas.
>> >>
>> >>
>> >> On 10/10/06, Patrick Steiner <patrick.steiner@a1.net> wrote:
>>> >>> Nicolas FR wrote:
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I am looking for a skilled C programmer to help me fixing the
>>>> >>>> matchbox-applet-cards. It can be done in less than two hours, but as I
>>>> >>>> have limited C knowledge I need some help.
>>>> >>>>
>>>> >>>> I hope someone would be willing to help fix this problem which is
>>>> >>>> quite annoying for OZ Gpe users (not having a working CF/SD applet).
>>>> >>>>
>>>> >>>> All we need to do is to be able to parse a config file in order to
>>>> >>>> find out the cardctl program used:
>>>> >>>> - pccardctl or cardctl
>>>> >>>> - the SD mount point
>>>> >>>> - if using a Spitz or not (to use the second CF slot instead of the
>>> >>> first).
>>>> >>>> Moreover the resulting app wil be able to run on any distro...
>>>> >>>>
>>>> >>>> The original apple source code is here:
>>>> >>>> http://mail.pdaxrom.org/src/mb-applet-cards-1.0.3.tar.bz2 (http://mail.pdaxrom.org/src/mb-applet-cards-1.0.3.tar.bz2)
>>>> >>>>
>>>> >>>> it's very simple (a single C file) and straightforward, so it will be
>>>> >>>> easy to improve.
>>>> >>>>
>>> >>> Have you already tried the version 1.0.2 (patched) from OE? i have build
>>> >>> a patch already
>>> >>>
>>> >>> regards,
>>> >>> patrick
>>> >>>
>>>> >>>> Thanks,
>>>> >>>> Nicolas.
>>>> >>>>
>>>> >>>>
>>> >>> -------------------------------------------------------------------------
>>> >>>
>>>> >>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> >>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> >>> share your
>>>> >>>> opinions on IT & business topics through brief surveys -- and earn
>>> >>> cash
>>> >>> http://www.techsay.com/default.php?page=jo...orge&CID=DEVDEV (http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV)
>>> >>>
>>>> >>>> _______________________________________________
>>>> >>>> Openzaurus-devel mailing list
>>>> >>>> Openzaurus-devel@lists.sourceforge.net
>>>> >>>> https://lists.sourceforge.net/lists/listinf...penzaurus-devel (https://lists.sourceforge.net/lists/listinfo/openzaurus-devel)
>>>> >>>>
>>>> >>>>
>>> >>>
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys -- and earn cash
> > http://www.techsay.com/default.php?page=jo...orge&CID=DEVDEV (http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV)
********** *END ENCRYPTED or SIGNED PART* **********
-
Hi Law!
Thanks for checking out DeviceHandler. I knew it depended upon HAL but I wasn't aware of the python and rox-lib dependencies, so I would agree that it isn't such a good choice for memory constrained embedded devices.