Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: vinu <vi...@hc...> - 2006-01-12 03:20:58
|
Hugo Vanwoerkom wrote: >Hi, > >I realize this is not a hot priority, but I have >repeatedly had the following: > >In a recent kernel (2.6.14/15) gpm (General Purpose >Mouse Interface) will act weird: the mouse cursor does >not show in a text console (not X), but a line copied >with gpm copy/paste will appear, *and* in mc lines are >selected wherever the mouse cursor moves. > >I only say "Faketty" in the subject line because that >is the multi-user setup that I am running with Debian >stable and nVidia closed source driver. > >I guess it will not happen if you don't copy/paste >with gpm. But that is just what gpm is handy for. > >Nothing fixes it: restarting gpm resumes in this >behavior. Logging out changes nothing. > >Hugo > > > > > >Hugo > > > > > > =09 >__________________________________________=20 >Yahoo! DSL =96 Something to write home about.=20 >Just $16.99/mo. or less.=20 >dsl.yahoo.com=20 > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick >_______________________________________________ >Linuxconsole-dev mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > > =20 > there's a possibility that the mouse configuration may go wrong. In the=20 case of some 3 buttn wheel mouse this problem is observerd. the simplest=20 to disable this is reconfigure gpm, as 3 button mouse only. Or 2 btn=20 mouse + emulate 3 buttons. regards vineesh |
|
From: Aivils S. <ai...@un...> - 2006-01-11 10:04:51
|
On Tre=F0diena, 11. Janv=E2ris 2006 11:22, Zephaniah E. Hull wrote: > On Wed, Jan 11, 2006 at 10:43:03AM +0200, Aivils Stoss wrote: > > On Pirmdiena, 9. Janv=E2ris 2006 16:33, Jean-Daniel Pauget wrote: > > > > so do we have a complete working patch for 2.6.15 now somewhere? > > > > where? > > > > - fix 2.6.15 compile issues > > - module and service have separate install commands > > > > http://www.ltn.lv/~aivils/files/faketty-0.05.tar.bz2 > > > > Unfortunately LED switch patch does not go into Linus tree > > because of silly objection. May be X guys will request that > > feature and then Andrew Morton applay it. If you use evdev > > of X, then you have same trouble of LEDs. > > I generally only skim this list, could you please provide more details > on the problem, and a link to the patch in question? Patch fix case , when 1st X uses old tty layer and 2nd (3rd...) X uses evdev driver. Without patch 1st X via tty switch LED's of all connected keyboards. http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm= 2/broken-out/input-keyboard_tasklet-dont-touch-leds-of-already-grabed-devic= e.patch Discusion: > Dmitry Torokhov <dmi...@gm...> wrote: > > > > On 1/6/06, Vojtech Pavlik <vo...@su...> wrote: > > > On Thu, Jan 05, 2006 at 10:36:41PM -0800, ak...@os... wrote: > > > > > > Fine with me. > > > > > > > From: Aivils Stoss <ai...@un...> > > > > > > > > Recent kernels allow exclusive usage of input device when input dev= ice=20 is > > > > grabbed. =A0keyboard_tasklet does not check device state and switch= =20 LED's of > > > > all keyboards. =A0However grabbed device may be use another LED ste= ering > > > > code. > > > > > > > > This patch forbid keyboard_tasklet switch LED's of grabbed devices. > > > > > >=20 > > The same objection as before - LED state is not synched back after > > device is released. We probably need "ungrab" hook somewhere... > >=20 >=20 > Ho hum. =A0I'll keep the patch queued and will doubtless resend it in a f= ew > weeks time. =A0One day someone will get sick of this and will fix it for= =20 real ;) We cannot sync back keyboard mapping, rate, LED state after "ungrab". I cannot understand view point of Dmitry Torokhov. Someone realy get sick if ungrabing became "hooked". Aivils |
|
From: Zephaniah E. H. <wa...@ae...> - 2006-01-11 09:23:08
|
On Wed, Jan 11, 2006 at 10:43:03AM +0200, Aivils Stoss wrote: > On Pirmdiena, 9. Janv=C4=81ris 2006 16:33, Jean-Daniel Pauget wrote: > > > so do we have a complete working patch for 2.6.15 now somewhere? > > > where? >=20 > - fix 2.6.15 compile issues > - module and service have separate install commands >=20 > http://www.ltn.lv/~aivils/files/faketty-0.05.tar.bz2 >=20 > Unfortunately LED switch patch does not go into Linus tree > because of silly objection. May be X guys will request that > feature and then Andrew Morton applay it. If you use evdev > of X, then you have same trouble of LEDs. I generally only skim this list, could you please provide more details on the problem, and a link to the patch in question? Thank you. Zephaniah E. Hull. --=20 1024D/E65A7801 Zephaniah E. Hull <wa...@ae...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. <knghtbrd> <Mercury> You don't have to be crazy to be a member of the=20 <knghtbrd> project, but you will be.. <=3D:] <knghtbrd> ^^^ was that a ref to debian or qf? I forget. <knghtbrd> =3D> <Mercury> knghtbrd: QF <knghtbrd> you sure? * knghtbrd was thinking maybe it was both <Mercury> It applies to both, but I was talking about QF at the time..=20 <G> <knghtbrd> ahh, okie. |
|
From: Aivils S. <ai...@un...> - 2006-01-11 08:39:10
|
On Pirmdiena, 9. Janv=E2ris 2006 16:33, Jean-Daniel Pauget wrote: > > so do we have a complete working patch for 2.6.15 now somewhere? > > where? =2D fix 2.6.15 compile issues =2D module and service have separate install commands http://www.ltn.lv/~aivils/files/faketty-0.05.tar.bz2 Unfortunately LED switch patch does not go into Linus tree because of silly objection. May be X guys will request that feature and then Andrew Morton applay it. If you use evdev of X, then you have same trouble of LEDs. Aivils |
|
From: Hugo V. <hvw...@ya...> - 2006-01-09 21:57:32
|
Hi, I realize this is not a hot priority, but I have repeatedly had the following: In a recent kernel (2.6.14/15) gpm (General Purpose Mouse Interface) will act weird: the mouse cursor does not show in a text console (not X), but a line copied with gpm copy/paste will appear, *and* in mc lines are selected wherever the mouse cursor moves. I only say "Faketty" in the subject line because that is the multi-user setup that I am running with Debian stable and nVidia closed source driver. I guess it will not happen if you don't copy/paste with gpm. But that is just what gpm is handy for. Nothing fixes it: restarting gpm resumes in this behavior. Logging out changes nothing. Hugo Hugo __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
|
From: Jean-Daniel P. <jd...@di...> - 2006-01-09 15:20:24
|
On Mon, Jan 09, 2006 at 03:13:34PM +0100, Andreas Schuldei wrote:
> On Thu, Jan 05, 2006 at 06:49:06AM -0800, Hugo Vanwoerkom wrote:
> >=20
> >=20
> > --- Jean-Daniel Pauget <jd...@di...> wrote:
> >=20
> > > by mistake I reversed the order of files in the
> > > previous post,
> > > here's the correct patch :
> >=20
> > <snip>
> >=20
> > Does the trick Jean-Daniel! Thanks!
>=20
> so do we have a complete working patch for 2.6.15 now somewhere?
> where?
yes, I posted it here just a few days ago.
you can now have it here :
http://disjunkt.com/dualhead/index.html#ftty
I'll also try to bring some clear instructions about faketty soon.
--=20
Jean-Daniel Pauget
T=E9l: +33 (0) 676 952 746
2, rue Andr=E9 PELCA
50580 Denneville-Plage
France
|
|
From: Ruben F. <par...@gm...> - 2006-01-09 14:29:51
|
Hi, I've tried multiseat X, using the new modular X.org 7.0. When booting the pc with 'Init display first : PCI' in the BIOS, everything works fine. I have to probe the NVidia GF2 card without -isolateDevice first, but afterwards, everything works. When using 'Init display first: AGP' however, the VBios of the Virge card isn't loaded, OR the wrong VBIOS is detected. I've tried with and without isolateDevice. This is the logfile: ... (++) ServerLayout "Workspace2" (**) |-->Screen "Workspace2" (0) (**) | |-->Monitor "elo_touchscreen" (**) | |-->Device "s3" (**) |-->Input Device "ps2_mouse" (**) |-->Input Device "at_keyboard" (**) Option "SingleCard" "true" (II) Isolating PCI bus "2:0:0" ... (II) LoadModule: "s3virge" (II) Loading /usr/lib/xorg/modules/drivers/s3virge_drv.so (II) Module s3virge: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.8.6 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.8 ... (II) S3VIRGE: driver (version 1.8.6) for S3 ViRGE chipsets: virge, 86C325, virge vx, 86C988, virge dx, virge gx, 86C375, 86C385, virge gx2, 86C357, virge mx, 86C260, virge mx+, 86C280, trio 3d, 86C365, trio 3d/2x, 86C362, 86C368 (II) Primary Device is: PCI 02:00:0 (--) Chipset virge found ... (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules/libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 7.0.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.8 (**) S3VIRGE(0): Depth 24, (--) framebuffer bpp 24 (==) S3VIRGE(0): RGB weight 888 (==) S3VIRGE(0): Default visual is TrueColor (==) S3VIRGE(0): Using HW Cursor (==) S3VIRGE(0): Using fb. (==) S3VIRGE(0): mx_cr3a_fix. ... (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules/libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.8 (II) S3VIRGE(0): initializing int10 (II) S3VIRGE(0): Primary V_BIOS segment is: 0xc000 (II) S3VIRGE(0): VESA BIOS detected (II) S3VIRGE(0): VESA VBE Version 3.0 (II) S3VIRGE(0): VESA VBE Total Mem: 4096 kB (II) S3VIRGE(0): VESA VBE OEM: NVidia (II) S3VIRGE(0): VESA VBE OEM Software Rev: 2.5 (II) S3VIRGE(0): VESA VBE OEM Vendor: NVidia (II) S3VIRGE(0): VESA VBE OEM Product: Riva TNT (II) S3VIRGE(0): VESA VBE OEM Product Rev: B1 (--) S3VIRGE(0): Chipset: "virge" (==) S3VIRGE(0): XVideo not supported. (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (II) S3VIRGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset is 0x0000 As you can see: (II) S3VIRGE(0): VESA VBE OEM: NVidia (II) S3VIRGE(0): VESA VBE OEM Software Rev: 2.5 (II) S3VIRGE(0): VESA VBE OEM Vendor: NVidia (II) S3VIRGE(0): VESA VBE OEM Product: Riva TNT (II) S3VIRGE(0): VESA VBE OEM Product Rev: B1 This is the NVIDIA BIOS that is detected... |
|
From: <an...@sc...> - 2006-01-09 14:13:55
|
On Thu, Jan 05, 2006 at 06:49:06AM -0800, Hugo Vanwoerkom wrote: > > > --- Jean-Daniel Pauget <jd...@di...> wrote: > > > by mistake I reversed the order of files in the > > previous post, > > here's the correct patch : > > <snip> > > Does the trick Jean-Daniel! Thanks! so do we have a complete working patch for 2.6.15 now somewhere? where? |
|
From: Aivils S. <ai...@un...> - 2006-01-09 09:20:14
|
Hi, All!
After few months of reading X code i discovered
old option. That option added into CVS tree 7 years ago
between 3.99 in 4.0.0 versions of XFree.
Syntaxis looks like this:
Section "ServerLayout"
Identifier "layout1"
InputDevice "Keyboard1" "CoreKeyboard"
InputDevice "Mouse1" "CorePointer"
Screen "screen1"
Inactive "DeviceName-1"
Inactive "DeviceName-2"
EndSection
I'm not sure, is syntax right.
Read about:
xc/programs/Xserver/hw/xfree86/RAC.Notes
Unfortunately that option lead segfault with X-6.8.2
of Mandriva. In the working case "Inactive" device beat
isolateDevice, because sysop can set up weird systems,
where 1st X have 3 heads, 2nd X - 5 heads ...
Aivils
|
|
From: Yitzhak B. G. <yit...@ya...> - 2006-01-08 16:03:28
|
Nice work on the stress testing, James. We must get to the bottom of this one of these days. Nvidia has not been responsive so far on our repeated reports of X crashes with multiple PCI boards. They don't even have a debugging procedure for multiple local X servers despite my and Mike Pardee's repeated requests. We have applied Aivils' patch to the Xorg X server and the results are very good. Specifically, Aivils didn't solve anything, rather he provided a workaround whereby logout (sending SIGHUP to the X server) will no longer force reset of the hardware video device. I doubt you will see a difference when performing <crtl><alt><bksp>, since that does force a hardware reset, but repeated crashes resulting from logins and logouts will either not occur at all or will become less frequent. Anyone wanting help in implementing aivils' patch is welcome to approach me for assistance. Yitzhak |
|
From: James v. Z. <ja...@dv...> - 2006-01-07 13:54:12
|
HT P4 3G: 2G RAM, 1x AGP NV, 1x PCI NV Open source drivers on FC4 xorg 6.8.2-37 are no good for multi-console? on P4, only a single console would work. Using text mode console, no console switching issues. <ctrl><alt><bkspc> stress test : On secondary (AGP) console _only_: secondary X failed after prolonged test, then both while attempting to recover - interestingly, it appears that at the point of failure the X server has accidentally come up on vt8 instead of (faketty) vt51. Trying to recover, I eventually took it to runlevel 1 and then discovered the X session running on vt8 - very slowly - drawing the login screen and taking mouse and keyboard input. <ctrl><alt><bkspc> seemed to terminate it, but X failed again on init 5. uptime=0 J On Sat, 2006-01-07 at 17:24 +1000, James van Zeeland wrote: > A bit more stress testing has revealed something interesting. > > On my two console server with 2.6.15-vz1 and nV binaries, I tried > performing a <ctrl><alt><bkspc> stress test on the secondary display > _only_. > > No crashes. At all. GDM complains about the X server restarting more > than 6 times in 90 seconds, pauses for two minutes then continues > loading X and we can do it all over again. > > Doing the same test with the primary console, after quite a few kills > will eventually cause a lockup and/or X crash. I inserted a 5 second > pause using an X wrapper, but results are the same. > > I am going to test again on another machine, this time trying open > source drivers as well as nV 8178 binaries. > > J -- James van Zeeland <ja...@dv...> |
|
From: James v. Z. <ja...@dv...> - 2006-01-07 07:14:35
|
A bit more stress testing has revealed something interesting. On my two console server with 2.6.15-vz1 and nV binaries, I tried performing a <ctrl><alt><bkspc> stress test on the secondary display _only_. No crashes. At all. GDM complains about the X server restarting more than 6 times in 90 seconds, pauses for two minutes then continues loading X and we can do it all over again. Doing the same test with the primary console, after quite a few kills will eventually cause a lockup and/or X crash. I inserted a 5 second pause using an X wrapper, but results are the same. I am going to test again on another machine, this time trying open source drivers as well as nV 8178 binaries. J -- James van Zeeland <ja...@dv...> |
|
From: Robbie H. <xy...@pa...> - 2006-01-06 12:33:05
|
<HTML><HEAD> </HEAD> <body bgcolor="#0066ff"> <DIV> <DIV align="center"><FONT face=Verdana size=5><font color="#808000"> <center> <table border=2 cellspacing=0 cellpadding=10 width=530 bordercolor=00DD6F> <tr><td bgcolor=FFFFFF> <font size=2 face=arial color=000000> <center><font color=F9A915 size=5 face=Verdana><b><center>Hot selling meds at cheeap<br><font color=FF9DFF>All countriess shiiping</font></font></b></center><br> Viaagrra, \/a1iium am, Lorazeepam, Cia1iis, Xanaax, Meridiia fly, Lipiitor, Zo1oft, Ambiien, Ce1ebrex, Sooma<br> & many more popular meds filledbeing<br><br> <center> <a target="_blank" href="http://pdepc.teshopat.com/?hedllletwecycv" ><font size=5 color=1C1CFF><u><b><font color="#2FDE03">CL1CK HERE TO 0RDER</font></font></font></b></u></a><br><br> </center> </td></tr></table> </xbody> </html> |
|
From: Hugo V. <hvw...@ya...> - 2006-01-05 14:49:16
|
--- Jean-Daniel Pauget <jd...@di...> wrote: > by mistake I reversed the order of files in the > previous post, > here's the correct patch : <snip> Does the trick Jean-Daniel! Thanks! Hugo __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
|
From: Jean-Daniel P. <jd...@di...> - 2006-01-05 10:09:50
|
by mistake I reversed the order of files in the previous post,
here's the correct patch :
-------------------------------------------------------------------------=
-
--- faketty-0.04/faketty.c 2005-10-01 17:14:16.000000000 +0200
+++ faketty-0.04-jd/faketty.c 2006-01-05 10:08:43.000000000 +0100
@@ -807,9 +805,16 @@ static struct input_handle *ftty_connect
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
dev->dev, "ftty%d", minor);
#else
- class_device_create(input_class,
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,15)
+ class_device_create(&input_class,
+ NULL,
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
dev->dev, "ftty%d", minor);
+#else
+ class_device_create(input_class,
+ MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
+ dev->dev, "ftty%d", minor);
+#endif
#endif
=20
=20
@@ -823,9 +828,14 @@ static void ftty_disconnect(struct input
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
class_simple_device_remove(MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + e=
vdev->minor));
#else
+#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,15)
+ class_device_destroy(&input_class,
+ MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + evde=
v->minor));
+#else
class_device_destroy(input_class,
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + evde=
v->minor));
#endif
+#endif
devfs_remove("input/ftty%d", evdev->minor);
evdev->exist =3D 0;
-------------------------------------------------------------------------=
-
--=20
Jean-Daniel Pauget
T=E9l: +33 (0) 676 952 746
2, rue Andr=E9 PELCA
50580 Denneville-Plage
France
|
|
From: Jean-Daniel P. <jd...@di...> - 2006-01-05 10:00:24
|
as from 2.6.15 I had to tweak faketty.c with the patch below in
order to match kernel changes.
I also had to create by myself the individual mouse devices nodes tha=
t
use to sit in /dev/input/mouse0, /dev/input/mouse1...
on my debian-sarge there's a tmpfs over /dev, and I'm not sure who's
duty it is to create those devices on the fly. is-it related to the
former devs ?
anyway, the patch below did the trick for me (regardless of those mou=
se
problems) :
--- faketty-0.04/faketty.c 2006-01-05 10:08:43.000000000 +0100
+++ /home/jd/src/faketty-0.04/faketty.c 2005-10-01 17:14:16.000000000 +02=
00
@@ -805,16 +807,9 @@ static struct input_handle *ftty_connect
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
dev->dev, "ftty%d", minor);
#else
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,15)
- class_device_create(&input_class,
- NULL,
+ class_device_create(input_class,
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
dev->dev, "ftty%d", minor);
-#else
- class_device_create(&input_class,
- MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + mino=
r),
- dev->dev, "ftty%d", minor);
-#endif
#endif
=20
=20
@@ -828,14 +823,9 @@ static void ftty_disconnect(struct input
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
class_simple_device_remove(MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + e=
vdev->minor));
#else
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,15)
- class_device_destroy(&input_class,
- MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + evde=
v->minor));
-#else
class_device_destroy(input_class,
MKDEV(INPUT_MAJOR, FTTY_MINOR_BASE + evde=
v->minor));
#endif
-#endif
devfs_remove("input/ftty%d", evdev->minor);
evdev->exist =3D 0;
--=20
Jean-Daniel Pauget
T=E9l: +33 (0) 676 952 746
2, rue Andr=E9 PELCA
50580 Denneville-Plage
France
|
|
From: Hugo V. <hvw...@ya...> - 2006-01-04 23:43:09
|
--- "Frederick W. Koehler" <fko...@co...> wrote: > I believe Aivils reply to my post on 11/15/05 (Re: > faketty-0.04 w/ > fedora rawhide...) contains the needed patch. > I thought there was more to it. The compiler complains about the 1st parm also, that is the class structure. The added NULL parameter is the 2nd parameter and that is the reason for the other warnings. Hugo > > Hugo Vanwoerkom wrote: > > >Hi, > > > >I get a compile error for Faketty in kernel 2.6.15: > > > >make[1]: Entering directory `/usr/src/linux-2.6.15' > > CC [M] /faketty-0.01/faketty.o > >/faketty-0.01/faketty.c: In function > `ftty_connect': > >/faketty-0.01/faketty.c:810: error: incompatible > type > >for argument 1 of `class_device_create' > >/faketty-0.01/faketty.c:810: warning: passing arg 2 > of > >`class_device_create' makes pointer from integer > >without a$ > >/faketty-0.01/faketty.c:810: warning: passing arg 3 > of > >`class_device_create' makes integer from pointer > >without a$ > >/faketty-0.01/faketty.c:810: warning: passing arg 4 > of > >`class_device_create' from incompatible pointer > type > >/faketty-0.01/faketty.c:810: warning: passing arg 5 > of > >`class_device_create' makes pointer from integer > >without a$ > >/faketty-0.01/faketty.c: In function > >`ftty_disconnect': > >/faketty-0.01/faketty.c:825: error: incompatible > type > >for argument 1 of `class_device_destroy' > >make[2]: *** [/faketty-0.01/faketty.o] Error 1 > >make[1]: *** [_module_/faketty-0.01] Error 2 > >make[1]: Leaving directory `/usr/src/linux-2.6.15' > >make: *** [module] Error 2 > > > >Regards, > > > >Hugo > > > > > > > > > >__________________________________________ > >Yahoo! DSL Something to write home about. > >Just $16.99/mo. or less. > >dsl.yahoo.com > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > >for problems? Stop! Download the new AJAX search > engine that makes > >searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > >_______________________________________________ > >Linuxconsole-dev mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > > > > > > > __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
|
From: Frederick W. K. <fko...@co...> - 2006-01-04 22:56:26
|
I believe Aivils reply to my post on 11/15/05 (Re: faketty-0.04 w/ fedora rawhide...) contains the needed patch. Frederick Koehler Hugo Vanwoerkom wrote: >Hi, > >I get a compile error for Faketty in kernel 2.6.15: > >make[1]: Entering directory `/usr/src/linux-2.6.15' > CC [M] /faketty-0.01/faketty.o >/faketty-0.01/faketty.c: In function `ftty_connect': >/faketty-0.01/faketty.c:810: error: incompatible type >for argument 1 of `class_device_create' >/faketty-0.01/faketty.c:810: warning: passing arg 2 of >`class_device_create' makes pointer from integer >without a$ >/faketty-0.01/faketty.c:810: warning: passing arg 3 of >`class_device_create' makes integer from pointer >without a$ >/faketty-0.01/faketty.c:810: warning: passing arg 4 of >`class_device_create' from incompatible pointer type >/faketty-0.01/faketty.c:810: warning: passing arg 5 of >`class_device_create' makes pointer from integer >without a$ >/faketty-0.01/faketty.c: In function >`ftty_disconnect': >/faketty-0.01/faketty.c:825: error: incompatible type >for argument 1 of `class_device_destroy' >make[2]: *** [/faketty-0.01/faketty.o] Error 1 >make[1]: *** [_module_/faketty-0.01] Error 2 >make[1]: Leaving directory `/usr/src/linux-2.6.15' >make: *** [module] Error 2 > >Regards, > >Hugo > > > >=09=09 >__________________________________________=20 >Yahoo! DSL =96 Something to write home about.=20 >Just $16.99/mo. or less.=20 >dsl.yahoo.com=20 > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through l= og files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLU= NK! >http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick >_______________________________________________ >Linuxconsole-dev mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > > =20 > |
|
From: Hugo V. <hvw...@ya...> - 2006-01-04 22:25:45
|
Hi, I get a compile error for Faketty in kernel 2.6.15: make[1]: Entering directory `/usr/src/linux-2.6.15' CC [M] /faketty-0.01/faketty.o /faketty-0.01/faketty.c: In function `ftty_connect': /faketty-0.01/faketty.c:810: error: incompatible type for argument 1 of `class_device_create' /faketty-0.01/faketty.c:810: warning: passing arg 2 of `class_device_create' makes pointer from integer without a$ /faketty-0.01/faketty.c:810: warning: passing arg 3 of `class_device_create' makes integer from pointer without a$ /faketty-0.01/faketty.c:810: warning: passing arg 4 of `class_device_create' from incompatible pointer type /faketty-0.01/faketty.c:810: warning: passing arg 5 of `class_device_create' makes pointer from integer without a$ /faketty-0.01/faketty.c: In function `ftty_disconnect': /faketty-0.01/faketty.c:825: error: incompatible type for argument 1 of `class_device_destroy' make[2]: *** [/faketty-0.01/faketty.o] Error 1 make[1]: *** [_module_/faketty-0.01] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.15' make: *** [module] Error 2 Regards, Hugo __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
|
From: Elise B. <kb...@es...> - 2006-01-04 02:10:41
|
St ock Alert iPackets International, Inc. Global Developer and Provider of a Wide Range of Wireless and Communications Solutions for Selected Enterprises Including Mine-Safety (Source: News 1/3/06) OTC: IPKL Price: .35 Huge PR For Wednesday is Underway on IPKL. Short/Day Trading Opportunity for You? Sometimes it is Bang-Zoom on These Small st ocks..As Many of You may Know Recent News: Go Read the Full Stories Now! 1)iPackets International Receives US$85,000 Down Payment for Its First iPMine Deployment in China 2)iPackets International Attends Several Mining Trade Shows and Receives Tremendous Response for Its iPMine Mine-Safety Product Watch This One Trade on Wednesday! Radar it Right Now.. _______________ Information within this email contains 4rward l00 king sta tements within meaning of Section 27A of the Sec urities Act of nineteen thirty three and Section 21B of the Se curities Exchange Act of nineteen thirty four. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions future events or performance are not statements of historical fact and may be 4rward 1o0king statements. 4rward looking statements are based on ex pectations, es timates and pr ojections at the time the statements are that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently featured Com pany is not a reporting company under the SEC Act of 1934 and there is limited information available on the company. The Co-mpany has a nominal ca sh position.It is an operating company. The company is going to need financing. If that financing does not occur, the company may not be able to continue as a going concern in which case you could lose your in-vestment. The pu blisher of this new sletter does not represent that the information contained in this mes sage states all material facts or does not omit a material fact necessary to make the statements therein not misleading. All information provided within this e_ mail pertaining to in-vesting, st 0cks, se curities must be understood as information provided and not inv estment advice. Remember a thorough due diligence effort, including a review of a company's filings when available, should be completed prior to in_vesting. The pub lisher of this news letter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in st0cks featured this e mail. None of the material within this report shall be construed as any kind of in_vestment advice or solicitation. Many of these com panies on the verge of bankruptcy. You can lose all your mony by inv esting in st 0ck. The publisher of this new sletter is not a registered in-vestment advis0r. Subscribers should not view information herein as legal, tax, accounting or inve stment advice. In com pliance with the Securities Act of nineteen thirty three, Section 17(b),The publisher of this newsletter is contracted to receive fifteen th0 usand d0 l1ars from a third party, not an off icer, dir ector or af filiate shar eh0lder for the ci rculation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias. All factual information in this report was gathered from public sources, including but not limited to Co mpany Press Releases. Use of the information in this e mail constitutes your acceptance of these terms. |
|
From: Peter S. <pet...@gm...> - 2005-12-31 19:02:52
|
Yes, I'm runnig this config. But I reported the problems on the second head regarding dpms on this list already. Config: debian - sid linux 2.4.14 nvidia 5600 (primary) matrox mystique (secondary) X11R7.0 evdev I'll give faketty a try, soon. Perhaps the dpms problems are sold then. Peter observer schrieb: >Hi, >Has anyone tried X11R7.0, or 6.9? >They have the isolate device feature and a new evedev input driver, >giving multiuser out of the box, its already in Fedora rawhide, but >after trying an update of fc4 in qemu I think i will have to wait >until fc5 test 2, the update didnt really break much but Im just not >ready to fix it > > > |
|
From: observer <obs...@bl...> - 2005-12-31 05:38:26
|
Hi, Has anyone tried X11R7.0, or 6.9? They have the isolate device feature and a new evedev input driver, giving multiuser out of the box, its already in Fedora rawhide, but after trying an update of fc4 in qemu I think i will have to wait until fc5 test 2, the update didnt really break much but Im just not ready to fix it |
|
From: Wilfred S. <yv...@ox...> - 2005-12-30 17:18:05
|
KO KO PETROLEUM (KKPT) - Friday Alert Up Over 100% Current Price: 1.60 Up $1.07 In Last 7 days Symbol - KKPT Watch out the sto ck go crazy Friday morning KOKO Petroleum, Inc. (KKPT) issued an update on its working interest investment in two wells in the prolific Barnett Shale Play located in northern Texas. Under the terms of the participation agreement with Rife Energy Operating, Inc. (the program's operator), KOKO Petroleum has acquired a minority working interests (approx. 10%) in the drilling and completion of two wells; the Boyd #1 and the Inglish #2 both of which have been drilled but not yet completed. The operator is in the process of setting casing on the Inglish 2 and the Boyd is awaiting a sufficient water supply to start the completion. Due to the heavy influx of major operators in the area (Encana and XTO), scheduling completions and any other types of oil field services has been very difficult. Operators in the area have had to schedule well completions three to four months in advance. This coupled with the fact that Northern Texas has experienced a major drought causing serious shortfalls of local water. Rife, as an alternative, has drilled a water well, which was the source of drilling water for the Inglish 2 and Boyd 1. Rife has five wells that have been drilled and are awaiting completions. The Barnett Shale is the largest natural gas play in Texas. It is presently producing 900 MMCF of gas per day and is considered one of the largest U.S. domestic natural gas plays with sizable, remaining resource potential. The first Barnett Shale wells were drilled and completed in the early 1980s by Mitchell Energy of Houston, Texas. According to an in-depth 2004 sector report on the Barnett Shale, developed by Morgan Stanley (MWD), the Barnett Shale play is estimated to hold reserves in the non-core area that could be as high as 150 BCF per 1,000 acres. The report estimated that because of the amount of gas available in the area, successful wells in the Barnett Shale should be economically viable in almost any gas price environment. "The well logs are very encouraging, as were the wells they offset. Our operator is very resourceful and we should have these wells completed by the end of the year," says Ted Kozub, President of KOKO Petroleum, Inc. On the Corsicana front, KOKO and its Partner have applied for the drilling permits to commence the first 15 Nacatoch wells, casing is being delivered to the site and drilling will commence upon receipt of the permits. |
|
From: - 2005-12-30 01:53:47
|
<HTML>
<head>
</head>
<BODY>
<DIV><FONT face=Tahoma size=2><BR><BR></FONT> </DIV>
<DIV><FONT face=Tahoma size=2><BR></FONT> </DIV>
<TABLE borderColor=#000000 cellSpacing=0 cellPadding=0 width=654 align=center
border=1>
<TBODY>
<TR>
<TD width=650>
<TABLE cellSpacing=0 cellPadding=3 width=650 align=center border=0>
<TBODY>
<TR bgColor=#003399>
<TD
style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"
bgColor=#008080 colSpan=2 height=46>
<P><FONT size=4><STRONG><FONT color=#ffffff>EMERGING GROWTH
ALERT</FONT></STRONG></P></FONT></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="541"><FONT color=#ffffff>Issue: 10725155</FONT></TD>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="101">
<DIV align=right><FONT color=#ffffff>DEC 2005</FONT></DIV></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px"
colSpan=2>
<DIV align=left></DIV>
<DIV align=left></DIV>
<TABLE cellSpacing=0 cellPadding=0 width=325 align=right border=1>
<TBODY>
<TR>
<TD>
<TABLE cellSpacing=0 cellPadding=3 width=325 align=right
border=1>
<TBODY>
<TR bgColor=#003399>
<TD bgColor=#008080 colSpan=2><b><font color="#FFFFFF">
KOKO PETROLEUM</font> </b><FONT color=#ffffff size=2><STRONG><BR>Undervalued
Special Situation</STRONG></FONT></TD></TR>
<TR>
<TD width="53%"><FONT size=2>Sy<B></B>mbol: </FONT></TD>
<TD width="47%"><em><font size="2"><b>KKPT</b></font></em></TD></TR>
<TR>
<TD><FONT size=2>52 Week Range</FONT></TD>
<TD>0.40 - 2.50</TD></TR>
<TR>
<TD><FONT size=2>Sha<B></B>res Float: </FONT></TD>
<TD><FONT size=2>25,000,000</FONT></TD></TR>
<TR>
<TD><FONT size=2>Current Price:</FONT></TD>
<TD><span class="468170001-22062005">
<font size="2" color="#0000FF">$1.60</font></span></TD></TR>
<TR>
<TD><FONT size=2>12 Mo.Target Price</FONT></TD>
<TD><FONT size=2>$8.70</FONT></TD></TR>
<TR>
<TD><FONT size=2> Last 5 days gain</FONT></TD>
<TD>$ 1.07</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P><EM><FONT color=#cc0000 size=4><STRONG>Breaking News
Alerts!<br>
Up $1.00 Last 7 days<br>
Up $.32 Dec 28th Alone</STRONG></FONT></EM></P>
<P><FONT color=#cc0000 size=3><STRONG><EM>Big News
Expected </EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> </FONT></SPAN><STRONG><EM>
Dec </EM></STRONG><SPAN><FONT color=#0000ff
size=2> </FONT></FONT><font size="3" color="#CC0000"><b><i>30</i></b></font><i><b><FONT color=#CC0000 size=3>th</FONT></b></i><FONT color=#0000ff
size=2> </FONT></SPAN><FONT color=#cc0000 size=3><BR><STRONG><EM>Value should
climb quickly!</EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> <br>
Be ready for the ride of your life, as
you<br>
can see so far </FONT></SPAN></FONT></P>
<P><EM><b>KOKO Petroleum Issues Update on Drilling</b> <b>Projects
in the Barnett Shale and Corsicana</b><br>
<br>
</EM><span class="t"><b>KOKO Petroleum, Inc. to Participate in
Barnett</b> <b>Shale Drilling Program</b></span><br>
<EM><br>
<br>
</EM><i> Petroleum and natural gas production in the Barnett
Shale play has been increasing steadily year after year. This is by
far one of the most active and prolific gas fields in America right
now and as such is garnering a lot of attention all the way from the
oil patch to Wall Street. The group that we have joined in this
Barnett Shale drilling program is affiliated with one of the major
stakeholders in the area with scores of wells already in production.
We are very confident in their proven ability to locate the best
drilling sites in the area and to efficiently tap the vast gas
resources held in Barnett Shale. This project is one of several next
steps in KOKO Petroleum's ongoing program to build a diverse
portfolio of promising oil and gas properties and prospects. We plan
to continue pursuing other promising prospects that should help us
build a diverse portfolio with long-term value for our
shareholders," says Mr. Ted Kozub, Chief Executive Officer of KOKO
Petroleum, Inc</i></P>
<P><i> The Barnett Shale is the largest natural gas play in
Texas. It is presently producing 900 MMCF of gas per day and is
considered one of the largest U.S. domestic natural gas plays with
sizable, remaining resource potential. The first Barnett Shale wells
were drilled and completed in the early 1980s by Mitchell Energy of
Houston, Texas. According to an in-depth 2004 sector report on the
Barnett Shale, developed by Morgan Stanley , the Barnett Shale play
is estimated to hold reserves in the non-core area that could be as
high as 150 BCF per 1,000 acres. The report estimated that because
of the amount of gas available in the area, successful wells in the
Barnett Shale should be economically viable in almost any gas price
environment. There are 75 rigs currently operating in the area.</i>
<EM> <BR><BR></EM><FONT size=2><EM><BR><BR></EM></FONT><B>
<FONT size=2><EM>KKPT is
getting ready to break out. We recommend this as a VERY Str()ng
buy.</EM></FONT></B></P>
<OL></OL></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2>
<P align=justify> </P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2 height=48>
</TD></TR></TBODY></TABLE><BR></BODY></HTML>
|
|
From: Aivils S. <ai...@un...> - 2005-12-27 08:51:41
|
On Sv=E7tdiena, 25. Decembris 2005 15:06, James van Zeeland wrote: > With multi-console at least, using this as a stress test will cause a > crash - either of the X server or a lockup or similar. It is attempting > to re-init immediately. How might one insert a pause of say 0.5 or 1 > second, to ensure that this is not the whole problem? Is this > unnecessary? I think at least gdm tried start up X 3 times with 5 sec time out. You can wrap X, start wrapper from a DM: #!/bin/bash sleep 1 exec Xorg $* Aivils |
1998 messages has been excluded from this view by a project administrator.
