pacebook-devel Mailing List for PaceBook Controls
Brought to you by:
zander
Menu
▾
▴
pacebook-devel — developer mails for all packages
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:26:52
|
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: Robert W. P. T. <ro...@pa...> - 2003-10-05 16:00:49
|
Alessandro Rubini schrieb: >Hi. > > > >>but there is also the easy way to just pass the plain DSDT.aml as initrd >>in the boot prompt or bootloader >>like >> >>initrd=/boot/MYDSDT.aml >> >> > >Yes, I've noticed. That's what was not clear to me, and I had to look >at the code to see what was going on. Besides, it's only compiled >in if initrd is configured, and I do not (ok, that's my fault, I know). > >It would be better to have "dsdt=" instead, but that would require >more work than this piggyback on initrd. > >Thanks a lot for bringing eth0 to another irq though, that's _great_. >[now there's audio and usb to split, but it's much less important] > > > strangly enough now that eth0 is on 7 ( i am testing eth0 on 6 since i had some issues i think ) the usb and sound harm good together on my system .... maybe the problem was the huge load that eth0 gave the IRQ 5 >/alessandro > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Pacebook-devel mailing list >Pac...@li... >https://lists.sourceforge.net/lists/listinfo/pacebook-devel > > > |
|
From: Alessandro R. <ru...@ar...> - 2003-10-05 08:24:31
|
>>I don't run the pbiod, as it turns the video off while I'm interactive >>over an USB keyboard, and that's not enjoyable. >> > this will be our next goal ,, and ill look at the xscreensaver code > since it should already be able to caputre the HID event`s ... The point is that X doesn't need anything special for blanking. Once the Xserver is configured to get input from several sources, it does it's dpms work independent of what the input is. i.e., no /proc/interrupts monitoring nor anything similar. I personally think pbiod is good to have for everything _but_ blanking. Each display engine (console or X) monitors its own input and does its DPMS right, whatever the input is (for example, I used to run a remote mouse on a laptop: UDP packets fed to a fifo and then gpm reading the fifo instead of /dev/ttyS0 -- blanking worked fine without special hacks). So you only may need the outb() added for this specific device, the rest is already dealt with. Actually, if I'm using both the panel and the external VGA I wouldn't like pbiod to blank the local screen but not the remote one. Not a serious problem at all, just a simptom that an external program can't do blanking right. /alessandro |
|
From: Alessandro R. <ru...@ar...> - 2003-10-05 08:24:31
|
Hi. > but there is also the easy way to just pass the plain DSDT.aml as initrd > in the boot prompt or bootloader > like > > initrd=/boot/MYDSDT.aml Yes, I've noticed. That's what was not clear to me, and I had to look at the code to see what was going on. Besides, it's only compiled in if initrd is configured, and I do not (ok, that's my fault, I know). It would be better to have "dsdt=" instead, but that would require more work than this piggyback on initrd. Thanks a lot for bringing eth0 to another irq though, that's _great_. [now there's audio and usb to split, but it's much less important] /alessandro |
|
From: Alessandro R. <ru...@ar...> - 2003-10-05 00:11:41
|
I'm one of the "startx" guys (no [xgk]dm). So my computers are often
in text mode (used over the network or just mail reading on a text
terminal).
The following trivial module deals with console blanking in text mode.
The X server already turns the video off (I'm running the vanilla
4.1.0 I found in Woody (Debian GNU/Linux).
I don't run the pbiod, as it turns the video off while I'm interactive
over an USB keyboard, and that's not enjoyable.
/alessandro
/* GPL 2 or later, but I doubt this trivial stuff is copyrightable */
#define __KERNEL__
#define MODULE
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/io.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Alessandro Rubini");
extern int (*console_blank_hook)(int);
int (*pbl_hook_save)(int);
int pbl_hook(int what)
{
if (what)
outb(0x99, 0xb1); /* light off with pacebook register */
else
outb(0x98, 0xb1); /* light on */
if (pbl_hook_save)
return pbl_hook_save(what);
return 0;
}
int pbl_init(void)
{
pbl_hook_save = console_blank_hook;
console_blank_hook = pbl_hook;
return 0;
}
void pbl_exit(void)
{
console_blank_hook = pbl_hook_save;
}
module_init(pbl_init);
module_exit(pbl_exit);
|
|
From: Alessandro R. <ru...@ar...> - 2003-10-04 23:44:33
|
I don't use initrd. I don't like it. It's too difficult for simple
minds like my own.
So I couldn't use your DSDT table as is. Actually, the procedure
is exceedingly intricate when the table is simply black magic
for everyone but a few people in the world. While I understand
that for those few people changing the table in a file is easier
than recompiling a new kernel, for me it just isn't.
So I chose the simple way: include the table as binary
data in the kernel image. This after reading your patch to
actually understand what was going on (the web page is really
not clear, but it's not your fault: the overall trick is quite
difficult to explain to the uninitiated).
My hack is just a few lines and works great. I'll need to port
it to 2.6.0 :)
This is the patch against the original osl.c file. Sure if you follow
this path you must also revert some other change to the vanilla
situation, but I bet you can just skip a patchset while making
your combined patch.
--- ./drivers/acpi/osl.c.orig Sat Oct 4 17:03:19 2003
+++ ./drivers/acpi/osl.c Sun Oct 5 01:39:39 2003
@@ -50,6 +50,10 @@
#define PREFIX "ACPI: "
+static unsigned char local_DSDT[] = {
+#include "DSDT.h"
+};
+
struct acpi_os_dpc
{
OSD_EXECUTION_CALLBACK function;
@@ -231,7 +235,10 @@
if (!existing_table || !new_table)
return AE_BAD_PARAMETER;
- *new_table = NULL;
+ if (!strncmp(existing_table->signature, "DSDT", 4))
+ *new_table = (struct acpi_table_header *)local_DSDT;
+ else
+ *new_table = NULL;
return AE_OK;
}
To generate the "DSDT.h" file, I just ran this Makefile:
DSDT.h: DSDT.aml
od -t x1 $^ | sed \
-e 's/^[0-7]* /0x/' \
-e 's/ /, 0x/g' \
-e 's/$$/,/' \
-e 's/^[0-7]*,$$/0x00/' \
> $@
|
|
From: Robert W. Paceblade/S. <ro...@pa...> - 2003-02-24 09:15:24
|
test -- _____________________________________ *Robert Woerle **Technical Support | Linux PaceBlade Technology Europe SA* phone: +49 89 552 99935 fax: +49 89 552 99910 mobile: +49 179 474 45 27 email: ro...@pa... <mailto:ro...@pa...> web: http://www.paceblade.com _____________________________________ |
