embedded
thanks for all the help, here is more info.: We plan on taking apart the kernal of the embedded OS. to fit it on a floppy make it like 200k or less. We are not really worrying about the applications, it'll be something at the end if we have time. ciara and ronan. hey Ronan and Ciara here, We are 3rd year computer science students doing a project. It involves building an embedded system. We are going to run an 486 embedded architecture emulator and we are considering what embedded operating system to run over this. We're probally going for TinyX or PicoGUI. Any thoughts, advantages disadvantages? http://www.may.ie ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
DDC Atoms Xinerama
I am attempting to do some things that are somewhat unconventional, and have so far been unable to find documentation on how to accomplish this. I have poted a similar query to some newsgroups, but so far have not got an answer I need. I am in the process of writing hardware / software monitor color calibration software for linux under Qt. In doing so, determining the monitor hardware that is currently running is quite paramount. The DDC seems to probe the monitors, then store this EDID data in an atom called XFree86_DDC_EDID1_RAWDATA While this method seems to work great in a single monitor environment, a Xinerama environment seems to be different. Since there seems to be a shared Screen between the Xinerama displays - is this EDID data still stored somewhere? Though the full EDID data would be nice, ultimately, I merely need a way off accociating specific screen coordinates to a monitor Vendor / Model / serial number triplet Any insight into this matter would be greatly apprecated Ben Guthro Sequel Imaging, Inc. -- Ben Guthro [EMAIL PROTECTED] Sequel Imaging, Inc. 603.425.2170 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DDC Atoms Xinerama
On 13 Mar 2003, Ben Guthro wrote: I am in the process of writing hardware / software monitor color calibration software for linux under Qt. In doing so, determining the monitor hardware that is currently running is quite paramount. The DDC seems to probe the monitors, then store this EDID data in an atom called XFree86_DDC_EDID1_RAWDATA While this method seems to work great in a single monitor environment, a Xinerama environment seems to be different. Since there seems to be a shared Screen between the Xinerama displays - is this EDID data still stored somewhere? Though the full EDID data would be nice, ultimately, I merely need a way off accociating specific screen coordinates to a monitor Vendor / Model / serial number triplet Any insight into this matter would be greatly apprecated Xcms is an existing industry standard color management scheme for X servers. It also uses atoms (such as XDCCC_LINEAR_RGB_MATRICES) to maintain state and make it available to applications/libraries. See man xcmsdb for the way one implementation handles these atoms. I haven't looked at the Xcms code for creating these atoms, so I don't know whether it copes with Xinerama. (I do have a program which can be used with xcmsdb to read XFree86_DDC_EDID1_RAWDATA and create the XDCCC_ atoms, but conventional wisdom is that the color data in many monitor EDIDs is worse than using established defaults - and I've seen figures to prove that). Xinerama didn't exist when I wrote the code for the atoms XFree86_DDC_EDID1_RAWDATA and XFree86_DDC_EDID2_RAWDATA, and I've never got around to looking at what to do. As you say, Xinerama presents a single screen, and thus properties on a single root window, but there are multiple sets of EDID data to present. I've heard talk of ways of refering to the separate heads for use in commands which take a display as argument, but I haven't seen anything working. With Xinerama, since a window may be moved between screens at any time (or appear on more than one at the same time) it isn't really appropriate for a client to ask about the monitor it is displayed on, but I can see that it may be sensible for configuration type applications to have access to both sets of monitor information at the same time. The X log file contains most of the EDID data (and I have a program which can parse most of it) so that might be the easiest way to get what you need. I haven't tried very hard, but I can't remember ever seeing correct EDID data for two monitors into the XFree86_DDC_EDID1_RAWDATA atoms of a dual head setup, and I would definitely not like to rely on it for a dual-head card. Sorry I can't be very positive. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A question about wide aspect panels
On Wed, 12 Mar 2003, Mark Cuss wrote: be a problem... The only one I'm not familiar with is the dot clock - how would a person go about figuring this out? Perhaps the panel is detected by DDC? In this case, you need no modeline. Last time I had a laptop that needed a modeline, the documentation of the graphics chip showed that in LCD mode, only a specific dot clock worked (50 MHz if I remember well, for 800x600). David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VESA FBconsole driver?
I wrote: A long time ago I remember there was a guy working on a VESA FBconsole driver for Linux. Then driver he was working on was structured as a user land daemon that the kernel console driver would call back into once the system was up, allowing the userland VESA driver to use the vm86() service to change modes, program the palette and other useful things that can't be done by the basic driver that uses a mode set previously by LILO or GRUB. No-one has responded to this email, so either no-one remembers this or people think someone else responded to my email ;-) Does anyone remember this project. I checked the Linux kernel and it presently does not seem to have any support for this. Can anyone point me at references that will help me figure out how the kernel can make callbacks into a user land daemon? My second question is, is it possible to execute vm86() services from *within* the kernel as opposed to from user land? I got the impression at the time that the userland daemon was used because vm86() could only be called from userland code and could not be called from within the kernel to execute real mode VESA BIOS services. Is that correct? If not, can vm86() services now be called from other kernel modules inside the kernel? I checked into this some more and it is clear that vm86() is only useable from userland code on Linux. However recently the FreeBSD kernels were modified to support vm86() from within the kernel, and in fact the latest FreeBSD VESA console driver uses the vm86() services so that it can do everything using the BIOS where necessary. Is there any reason why the vm86() services in the Linux kernel cannot be used by other kernel code? Has anyone made an attempt to update the vm86() services to support this? Thanks! --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VESA FBconsole driver?
On Thu, 13 Mar 2003, Kendall Bennett wrote: I wrote: A long time ago I remember there was a guy working on a VESA FBconsole driver for Linux. Then driver he was working on was structured as a user land daemon that the kernel console driver would call back into once the system was up, allowing the userland VESA driver to use the vm86() service to change modes, program the palette and other useful things that can't be done by the basic driver that uses a mode set previously by LILO or GRUB. No-one has responded to this email, so either no-one remembers this or people think someone else responded to my email ;-) I think you just have the wrong mailing list. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Some patches to luit
Hello, list,
It seems xc/programs/luit/sys.c in XFree86 4.3.0 contains a off-by-one
bug. A patch (sys.c.patch) to fix this is attached.
Besides, I have some more modifications to luit which is useful on
FreeBSD:
- Make luit use openpty to search an unused pty. Without this patch,
luit aborts after opening ten or so xterms.
- Allow one to setuid luit.
The patch to modify these is attached (luit-freebsd.patch). To try
it, apply this patch instead of sys.c.patch.
Best regards,
Tsuyoshi
--- ITO Tsuyoshi [EMAIL PROTECTED] ---
--- Dept. of Computer Science, University of Tokyo. ---
--- xc/programs/luit/sys.c.orig Tue Jan 8 05:38:30 2002
+++ xc/programs/luit/sys.c Fri Mar 14 13:17:15 2003
@@ -373,7 +373,7 @@
goto bail;
found:
-line = malloc(strlen(name));
+line = malloc(strlen(name) + 1);
strcpy(line, name);
line[5] = 't';
fix_pty_perms(line);
--- xc/programs/luit/Imakefile.orig Thu Oct 17 10:06:09 2002
+++ xc/programs/luit/Imakefile Tue Mar 11 03:19:58 2003
@@ -8,7 +8,7 @@
LOCAL_LIBRARIES = $(XFONTENCLIB)
DEPLIBS = $(DEPXFONTENCLIB)
-SYS_LIBRARIES = MathLibrary GzipLibrary
+SYS_LIBRARIES = MathLibrary GzipLibrary -lutil
SRCS = luit.c iso2022.c charset.c parser.c sys.c other.c
--- xc/programs/luit/luit.c.origMon Feb 24 10:10:25 2003
+++ xc/programs/luit/luit.c Tue Mar 11 04:04:53 2003
@@ -439,8 +439,8 @@
condom(int argc, char **argv)
{
int pty;
+int tty;
int pid;
-char *line;
char *path;
char **child_argv;
int rc;
@@ -450,7 +450,7 @@
if(rc 0)
FatalError(Couldn't parse arguments\n);
-rc = allocatePty(pty, line);
+rc = allocatePty(pty, tty);
if(rc 0) {
perror(Couldn't allocate pty);
exit(1);
@@ -470,11 +470,11 @@
if(pid == 0) {
close(pty);
-child(line, path, child_argv);
+child(tty, path, child_argv);
} else {
+close(tty);
free(child_argv);
free(path);
-free(line);
parent(pid, pty);
}
@@ -482,9 +482,8 @@
}
void
-child(char *line, char *path, char **argv)
+child(int tty, char *path, char **argv)
{
-int tty;
int pgrp;
close(0);
@@ -496,8 +495,7 @@
exit(1);
}
-tty = openTty(line);
-if(tty 0) {
+if(openTty(tty) 0) {
kill(getppid(), SIGABRT);
exit(1);
}
diff -ru old/xc/programs/luit/luit.h new/xc/programs/luit/luit.h
--- xc/programs/luit/luit.h.origFri Nov 2 12:06:43 2001
+++ xc/programs/luit/luit.h Tue Mar 11 04:04:03 2003
@@ -26,6 +26,6 @@
extern int ilog;
extern int olog;
-void child(char*, char*, char**);
+void child(int, char*, char**);
void parent(int, int);
--- xc/programs/luit/sys.c.orig Tue Jan 8 05:38:30 2002
+++ xc/programs/luit/sys.c Tue Mar 11 06:54:05 2003
@@ -33,6 +33,7 @@
#include termios.h
#include signal.h
#include errno.h
+#include libutil.h
#ifdef SVR4
#define HAVE_POLL
@@ -276,17 +277,17 @@
}
static int
-fix_pty_perms(char *line)
+fix_pty_perms(int tty)
{
int rc;
struct stat s;
int uid = getuid(), gid = getgid();
-rc = stat(line, s);
+rc = fstat(tty, s);
if(rc 0)
return -1;
if(s.st_uid != uid || s.st_gid != gid) {
-rc = chown(line, getuid(), getgid());
+rc = fchown(tty, getuid(), getgid());
if(rc 0) {
fprintf(stderr,
Warning: could not change ownership of tty --
@@ -295,7 +296,7 @@
}
}
if((s.st_mode 0777) != (S_IRUSR | S_IWUSR | S_IWGRP)) {
-rc = chmod(line, S_IRUSR | S_IWUSR | S_IWGRP);
+rc = fchmod(tty, S_IRUSR | S_IWUSR | S_IWGRP);
if (rc 0) {
fprintf(stderr,
Warning: could not change permissions of tty --
@@ -307,98 +308,23 @@
}
int
-allocatePty(int *pty_return, char **line_return)
+allocatePty(int *pty_return, int *tty_return)
{
-char name[12], *line = NULL;
-int pty = -1;
-char *name1 = pqrstuvwxyzPQRST, *name2 = 0123456789abcdef;
-char *p1, *p2;
+int pty;
+int tty;
-#ifdef HAVE_GRANTPT
-char *temp_line;
-int rc;
-
-pty = open(/dev/ptmx, O_RDWR);
-if(pty 0)
-goto bsd;
-
-rc = grantpt(pty);
-if(rc 0) {
-close(pty);
-goto bsd;
-}
-
-rc = unlockpt(pty);
-if(rc 0) {
-close(pty);
-goto bsd;
-}
-
-temp_line = ptsname(pty);
-if(!temp_line) {
-close(pty);
-goto bsd;
-}
-line = malloc(strlen(temp_line) + 1);
-if(!line) {
-close(pty);
+if (openpty(pty, tty, NULL, NULL, NULL) == -1)
return -1;
-}
-strcpy(line, temp_line);
-
-fix_pty_perms(line);
-
-*pty_return = pty;
-*line_return = line;
-return 0;
-
- bsd:
-#endif /* HAVE_GRANTPT */
-
-strcpy(name, /dev/pty??);
-for(p1 = name1; *p1; p1++) {
-name[8] = *p1;
-for(p2 = name2; *p2; p2++) {
-
Re: VESA FBconsole driver?
On Thu, 13 Mar 2003, Kendall Bennett wrote: Mark Vojkovich [EMAIL PROTECTED] wrote: No-one has responded to this email, so either no-one remembers this or people think someone else responded to my email ;-) I think you just have the wrong mailing list. Actually I posted here deliberately in the hope that someone on this list may know about this project since it is graphics related. No-one seems to want to respond to me in the Linux lists. I think that the problem is that almost noone here knows about FBconsole type things, so we have nothing constructive to say. It isn't that we don't want to anser, just that we don't have answers to your questions. I personally feel that XFree86 has benefited from your contributions and such a close comparison/interaction with your product. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
