Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Eject Key on PPC
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC
View previous topic :: View next topic  
Author Message
simon_b
n00b
n00b


Joined: 03 Jun 2004
Posts: 46
Location: Hamilton, NZ

PostPosted: Sat Nov 06, 2004 5:19 am    Post subject: Eject Key on PPC Reply with quote

I've installed PPC64 on my G5 but i have a problem in that i cant eject the superdrive! how do you setup the special keys on the apple keyboard in gentoo?
Back to top
View user's profile Send private message
makke
n00b
n00b


Joined: 19 Feb 2004
Posts: 32
Location: Sweden/Umea

PostPosted: Sat Nov 06, 2004 8:58 am    Post subject: Eject Reply with quote

You can eject your superdrive via the program cdrecord with an argument called -eject.

Should be possible to get a key to do that.
_________________
AMD Athlon64 3200+, MSI K8 Neo-FSR, 1024Mb Crucial DDR400, Dell 2405FPW 24", Maxtor 200Gb Sata runs gentoo and now Xgl with Compiz

MacBook 1.83GHz /1024Mb /80Gb White, Solid MAN!
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Sat Nov 06, 2004 3:53 pm    Post subject: Reply with quote

Did you try
Code:
eject

from the command line? That does the trick usually. ;-) You may want then to take a look at evkey to bind a key to this action.
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
Hydraulix
Guru
Guru


Joined: 12 Dec 2003
Posts: 447
Location: Baltimore, Maryland

PostPosted: Sun Nov 07, 2004 10:53 am    Post subject: Reply with quote

Code:
emerge pbbuttonsd


Then edit pbbuttonsd.conf and change the "EjectCDKey" to whatever key you want. I'd recommend the command "showkey" to get the number of the key you want to use to eject the superdrive.
_________________
It is the fate of operating systems to become free.
- Neal Stephenson

If only You and Dead people can read hex, how many people can read hex?
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Sun Nov 07, 2004 4:46 pm    Post subject: Reply with quote

It is said that evkeyd (with a terminating d which I missed in my previous post, sorry) is better for desktops (pbbuttonsd being especially tailored to laptops). I have never tried any of them on a non-laptop machine, but people have reported in the past of being happy with evkeyd.
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
simon_b
n00b
n00b


Joined: 03 Jun 2004
Posts: 46
Location: Hamilton, NZ

PostPosted: Sun Nov 07, 2004 8:30 pm    Post subject: Reply with quote

thanks guys! im going to try your suggestions :)
Back to top
View user's profile Send private message
fb
l33t
l33t


Joined: 08 Dec 2003
Posts: 636
Location: New Zealand

PostPosted: Sun Nov 07, 2004 10:46 pm    Post subject: Reply with quote

bruda wrote:
It is said that evkeyd (with a terminating d which I missed in my previous post, sorry) is better for desktops (pbbuttonsd being especially tailored to laptops). I have never tried any of them on a non-laptop machine, but people have reported in the past of being happy with evkeyd.


Very interesting I was wondering if you could do that for a while.
I am using kde and i usually right click on my cd icon and select
eject to open my drive. Having a key would be better.

Can we go one better? I usually push my tray (iMac G4) in to
close it. Could we have it to close as well with the same button
like in OSX?
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Mon Nov 08, 2004 12:53 am    Post subject: Reply with quote

fb wrote:
Can we go one better? I usually push my tray (iMac G4) in to close it. Could we have it to close as well with the same button like in OSX?

The command is of course
Code:
eject -t

I am sure there are ways to bind this to a key (how to do this depends on your environment though), but this I have really not tried. Maybe evkeyd does this already...
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
fb
l33t
l33t


Joined: 08 Dec 2003
Posts: 636
Location: New Zealand

PostPosted: Mon Nov 08, 2004 1:41 am    Post subject: Reply with quote

I just tried evkeyd for fun and have those keys working
but I have an unexpected problem. The deamon seems
to start normally but quit. Running "evkeyd --debug" revealed
the following interesting info:
Code:
bash-2.05b# evkeyd --debug
evkeyd[15461] debug: event_init
evkeyd[15461] fatal error: Couldn't find the appropriate event device


I guess I need something to be compiled in the kernel but what?
:?
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Mon Nov 08, 2004 3:48 am    Post subject: Reply with quote

Is there any output for
Code:
ls -l /dev/input/event*

on your system? In not then you need to set CONFIG_INPUT_EVDEV in your kernel configuration (Device Drivers -> Input device support -> Event interface). (Also make sure you do not set the associated debug option unless you want to have a log entry for each and every key you press. ;-) )

Now that I started all of this I tried to build the thing and I get slapped with a compile-time error (backlight.c:23: error: subscripted value is neither array nor pointer). I did compile it one time (GCC 3.3.something) without any problems, but now (GCC 3.4.1) the thing fails on me and worst I don't have any idea why (line 23 and its surroundings look fine as far as I can tell). What version of GCC are you using?
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
fb
l33t
l33t


Joined: 08 Dec 2003
Posts: 636
Location: New Zealand

PostPosted: Mon Nov 08, 2004 4:02 am    Post subject: Reply with quote

bruda wrote:
Is there any output for
Code:
ls -l /dev/input/event*

on your system? In not then you need to set CONFIG_INPUT_EVDEV in your kernel configuration (Device Drivers -> Input device support -> Event interface). (Also make sure you do not set the associated debug option unless you want to have a log entry for each and every key you press. ;-) )


No such file. So I will look into that.
bruda wrote:

Now that I started all of this I tried to build the thing and I get slapped with a compile-time error (backlight.c:23: error: subscripted value is neither array nor pointer). I did compile it one time (GCC 3.3.something) without any problems, but now (GCC 3.4.1) the thing fails on me and worst I don't have any idea why (line 23 and its surroundings look fine as far as I can tell). What version of GCC are you using?


Same gcc here [gcc version 3.4.1 20040803 (Gentoo Linux 3.4.1-r3, ssp-3.4-2, pie-8.7.6.5].
It did compile fine, twice. Strange error, I am tempted to
ask about your CFLAGS but I cannot think of one that would
produce that kind of message. I suppose you use evkeyd-0.1_pre7
from the portage tree?
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Mon Nov 08, 2004 4:13 am    Post subject: Reply with quote

That's the crazyest thing I have ever seen: the compilation problem mentioned in my previous message goes away when one applies the following patch:
Code:
--- backlight.c.original        2004-11-07 23:03:52.953648120 -0500
+++ backlight.c 2004-11-07 23:05:50.963707864 -0500
@@ -20,7 +20,7 @@

        int fd = open(DEV_PMU, O_RDWR);

-        if(ioctl(fd, _IOR('B', 6, 0), 0) < 0) {
+        if(ioctl(fd, PMU_IOC_GRAB_BACKLIGHT, 0) < 0) {
                log_warn(cfg, "couldn't grab backlight");
                cfg->backlight_enable = 0;
                close(fd);

Notice that _IOR('B', 6, 0) is replaced with PMU_IOC_GRAB_BACKLIGHT and that's the only difference. Now comes the fun part: PMU_IOC_GRAB_BACKLIGHT is defined in evkeyd.h (line 51) like this:
Code:
#define PMU_IOC_GRAB_BACKLIGHT      _IOR('B', 6, 0)

There is thus no real difference between the two versions, except that one builds and the other does not. Could anybody explain this by chance?
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Mon Nov 08, 2004 4:17 am    Post subject: Reply with quote

fb wrote:
No such file. So I will look into that.

Then that's it probably. After the crazy fix evkeyd builds fine and works (or at least initializes itself, will look into configuration and stuff tomorrow).
fb wrote:
Same gcc here [gcc version 3.4.1 20040803 (Gentoo Linux 3.4.1-r3, ssp-3.4-2, pie-8.7.6.5]. It did compile fine, twice. Strange error

Strange indeed, but I challenge you to find somethig stranger than my fix. :lol:
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
fb
l33t
l33t


Joined: 08 Dec 2003
Posts: 636
Location: New Zealand

PostPosted: Mon Nov 08, 2004 9:50 pm    Post subject: Reply with quote

bruda wrote:
That's the crazyest thing I have ever seen: the compilation problem mentioned in my previous message goes away when one applies the following patch:
Code:
--- backlight.c.original        2004-11-07 23:03:52.953648120 -0500
+++ backlight.c 2004-11-07 23:05:50.963707864 -0500
@@ -20,7 +20,7 @@

        int fd = open(DEV_PMU, O_RDWR);

-        if(ioctl(fd, _IOR('B', 6, 0), 0) < 0) {
+        if(ioctl(fd, PMU_IOC_GRAB_BACKLIGHT, 0) < 0) {
                log_warn(cfg, "couldn't grab backlight");
                cfg->backlight_enable = 0;
                close(fd);

Notice that _IOR('B', 6, 0) is replaced with PMU_IOC_GRAB_BACKLIGHT and that's the only difference. Now comes the fun part: PMU_IOC_GRAB_BACKLIGHT is defined in evkeyd.h (line 51) like this:
Code:
#define PMU_IOC_GRAB_BACKLIGHT      _IOR('B', 6, 0)

There is thus no real difference between the two versions, except that one builds and the other does not. Could anybody explain this by chance?


Not that I can think of. In one case parsing your source is all right
and in the other it isn't... CFLAGS? I see from an other post
that you are on ppc64, may be you just found a compiler bug.

Now the interesting question how did you think of doing that? 8O
I know I sometime surprise myself when I find bugs but this
one is stretching my understanding quite a bit.
Back to top
View user's profile Send private message
bruda
Guru
Guru


Joined: 06 May 2004
Posts: 376
Location: Sherbrooke, QC, Canada

PostPosted: Mon Nov 08, 2004 11:34 pm    Post subject: Reply with quote

fb wrote:
Not that I can think of. In one case parsing your source is all right and in the other it isn't... CFLAGS? I see from an other post that you are on ppc64, may be you just found a compiler bug.

I have a ppc64 but all of this happened on the good ol' ppc32 (my wife's machine if you want to know). I did not include any CFLAGS for these tests, so they are probably not the cuplrit. Somebody on the Bishop's (local) fora suggested that I have some gremlins in my machine which seems a plausible explanation. :-D

Seriously, I am sure this reflects a bug somewhere in the tool chain (GCC or maybe kernel headers) but how on Earth can one report it since it disappears when one writes two identical programs with only one difference that should not matter and still obtain different results. In any case, maybe one time I will figure it out or at least figure out a reproducible case study so that I can file a bug report. :roll:
fb wrote:
Now the interesting question how did you think of doing that? 8O I know I sometime surprise myself when I find bugs but this one is stretching my understanding quite a bit.

Call it intuition. :-D Seriously, I don't remember the line of thoughts that led to the fix. I believe I just grepped for _IOR (and discovered the macro) and also looked at the next function (which uses a macro instead of directly a _IOR) so I said what the heck let's try it out. It was at that time probably just an attempt to make the code consistent and thus easier to figure out...
_________________
Quid latine dictum sit altum videtur
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum