Re: [patch] nonblinking VGA block cursor
On Sat, 16 Jun 2001, Daniel Phillips wrote: > Ask the original poster if he's willing to take the risk of going with an xor > cursor. We are talking text mode, right? No way to get rid of that blinking > text cursor, ever. Tell me, do you like having the colon blink on your alarm > clock too? Personally, I opened the thing up and put a piece of tape over it. > Aha! A software weenie! A real hardware hacker would have snipped and soldered it to VCC to get a constant (or add a switch for solid/blink =). In any case, this strikes me as a matter of policy. I don't care one way or the other, but if people want a solid cursor, it's not something that we can really deny them that (unless it's a binary-only driver for the cursor, of course). Anyway, this is a silly discusson in general, i figured i would throw in my $0.02 (strong US cents!) > IBM had lots of ideas about how computers should work. Remember the keyboard > keys that when CLACK CLACK CLACK. Thank god they turned out to be too > expensive to clone - nobody misses them now. > *CLACK CLACK CLACK* (posted with a Model M) -- /jbm, but you can call me Josh. Really, you can. "When lasers are outlawed, only outlaws will have lasers" -- from http://www.altair.org/CO2laser.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Sat, 16 Jun 2001, Daniel Phillips wrote: Ask the original poster if he's willing to take the risk of going with an xor cursor. We are talking text mode, right? No way to get rid of that blinking text cursor, ever. Tell me, do you like having the colon blink on your alarm clock too? Personally, I opened the thing up and put a piece of tape over it. Aha! A software weenie! A real hardware hacker would have snipped and soldered it to VCC to get a constant (or add a switch for solid/blink =). In any case, this strikes me as a matter of policy. I don't care one way or the other, but if people want a solid cursor, it's not something that we can really deny them that (unless it's a binary-only driver for the cursor, of course). Anyway, this is a silly discusson in general, i figured i would throw in my $0.02 (strong US cents!) IBM had lots of ideas about how computers should work. Remember the keyboard keys that when CLACK CLACK CLACK. Thank god they turned out to be too expensive to clone - nobody misses them now. *CLACK CLACK CLACK* (posted with a Model M) -- /jbm, but you can call me Josh. Really, you can. When lasers are outlawed, only outlaws will have lasers -- from http://www.altair.org/CO2laser.htm - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major Clock Drift
Hello again, When i originally posted this, it was _highly_ OT. the machine in question runs windows ME, but i figured the best place to find hardware gurus was here. the topic has rather degraded, and while i enjoy getting mail from alan, the fact that it has nothing to do with me dampens the enthusiasm =) if you're going to go changing the subject, at least mention framebuffers, as that seems to be the common thread. if you all could de-cc me on these, it'd be appreciated. -- - josh On Mon, 12 Feb 2001, george anzinger wrote: > I may be off base here, but the problem as described below does _NOT_ > seem to be OT so I removed that from the subject line. A clock drift > change with an OS update is saying _something_ about the OS, not the > hardware. In this case it seems to be the 2.4.x OS that is loosing > time. I suspect the cause is some driver that is not being nice to the > hardware, either by abusing the interrupt off code or locking up the bus > or some such. In any case I think it should _not_ be considered OT. > > George -- /jbm, but you can call me Josh. Really, you can. Rap-Rock is neither Modern nor Alternative. Not that I'm bitter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major Clock Drift
Hello again, When i originally posted this, it was _highly_ OT. the machine in question runs windows ME, but i figured the best place to find hardware gurus was here. the topic has rather degraded, and while i enjoy getting mail from alan, the fact that it has nothing to do with me dampens the enthusiasm =) if you're going to go changing the subject, at least mention framebuffers, as that seems to be the common thread. if you all could de-cc me on these, it'd be appreciated. -- - josh On Mon, 12 Feb 2001, george anzinger wrote: I may be off base here, but the problem as described below does _NOT_ seem to be OT so I removed that from the subject line. A clock drift change with an OS update is saying _something_ about the OS, not the hardware. In this case it seems to be the 2.4.x OS that is loosing time. I suspect the cause is some driver that is not being nice to the hardware, either by abusing the interrupt off code or locking up the bus or some such. In any case I think it should _not_ be considered OT. George -- /jbm, but you can call me Josh. Really, you can. Rap-Rock is neither Modern nor Alternative. Not that I'm bitter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sync & asyck i/o
Hello, On Tue, 6 Feb 2001, Alan Cox wrote: [snip] > In theory for a journalling file system it means the change is committed to the > log and the log to the media, and for other fs that the change is committed > to the final disk and recoverable by fsck worst case > > In practice some IDE disks do write merging and small amounts of write > caching in the drive firmware so you cannot trust it 100%. In addition some > higher end controllers will store to battery backed memory caches which is > normally just fine since the reboot will play through the ram cache. > Does this imply that in order to ensure my data hits the drives, i should do a warm reboot and then shut down from the lilo: prompt or similiar? apologies to bug you with a simple question, but i can see other people worrying about data loss here too. -- /jbm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sync asyck i/o
Hello, On Tue, 6 Feb 2001, Alan Cox wrote: [snip] In theory for a journalling file system it means the change is committed to the log and the log to the media, and for other fs that the change is committed to the final disk and recoverable by fsck worst case In practice some IDE disks do write merging and small amounts of write caching in the drive firmware so you cannot trust it 100%. In addition some higher end controllers will store to battery backed memory caches which is normally just fine since the reboot will play through the ram cache. Does this imply that in order to ensure my data hits the drives, i should do a warm reboot and then shut down from the lilo: prompt or similiar? apologies to bug you with a simple question, but i can see other people worrying about data loss here too. -- /jbm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] Major Clock Drift
Hello all, I know this _really_ isn't the forum for this, but a friend of mine has noticed major, persistent clock drift over time. After several weeks, the clock is several minutes slow (always slow). Any thoughts on the cause? (Google didn't show up anything worthwhile in the first couple of pages, so i gave up). I assume it doens't matter what the mains frequency is (since we're pulling from a crystal for this anyway). I think i'd heard mention of problems with other interrupts interrupting the timer often enough that the time got slowed down, but really? It's a relatively new Athlon, not sure of the mobo model. If it is a hardware problem, i'll find out the model, since that would strike me as an errata =) Thanks for indulging an idle hardware question -- /jbm, but you can call me Josh. Really, you can. Rap-Rock is neither Modern nor Alternative. Not that I'm bitter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] Major Clock Drift
Hello all, I know this _really_ isn't the forum for this, but a friend of mine has noticed major, persistent clock drift over time. After several weeks, the clock is several minutes slow (always slow). Any thoughts on the cause? (Google didn't show up anything worthwhile in the first couple of pages, so i gave up). I assume it doens't matter what the mains frequency is (since we're pulling from a crystal for this anyway). I think i'd heard mention of problems with other interrupts interrupting the timer often enough that the time got slowed down, but really? It's a relatively new Athlon, not sure of the mobo model. If it is a hardware problem, i'll find out the model, since that would strike me as an errata =) Thanks for indulging an idle hardware question -- /jbm, but you can call me Josh. Really, you can. Rap-Rock is neither Modern nor Alternative. Not that I'm bitter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
We would never parody Monty Python! This is an excerpt from Judas, one of the gospels that was in dispute. I'm sorry, I must go, as there's a man in a military uniform here, shouting at me to stop being silly... -josh On Sat, 20 Jan 2001 23:58:07 Mike A. Harris wrote: > On Sun, 21 Jan 2001, Admin Mailing Lists wrote: > > >> And the lord spake, saying, "First shalt thou write thy holy code. . > If I'm not mistaken, the above is a parody on Monty Python's Holy > Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's > been a while.. > . (i modified Mike's copyrighted document. do i need to get a license from all of the people he quoted as well as his? ;^) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
We would never parody Monty Python! This is an excerpt from Judas, one of the gospels that was in dispute. I'm sorry, I must go, as there's a man in a military uniform here, shouting at me to stop being silly... -josh On Sat, 20 Jan 2001 23:58:07 Mike A. Harris wrote: On Sun, 21 Jan 2001, Admin Mailing Lists wrote: And the lord spake, saying, "First shalt thou write thy holy code. . If I'm not mistaken, the above is a parody on Monty Python's Holy Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's been a while.. . (i modified Mike's copyrighted document. do i need to get a license from all of the people he quoted as well as his? ;^) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 128M memory OK, but with 192M sound card es1391 trouble
You're probably just hearing electrical noise from the memory buss; try moving the 128 stick to the slot you put the 64 in (if you can) and run that way -- you'll probably hear it there too. I get something similiar to this with my SB Live (!... damn marketroids) on a BP6 with 192MB as well. In my case, it's not during DSP use per se, but during memory activity. Try dragging a window around in X and listen for buzzing. My guess is that JA's console player doesn't move around as much memory as the gnome one (imagine that), therefore produces less memory noise. -- /jbm, but you can call me Josh. Really, you can. "car. snow. slippery. wheee. dead josh. car slipped on ice." -- Manda explaining my purchase of kitty litter On Wed, 17 Jan 2001 17:25:51 J . A . Magallon wrote: > > On 2001.01.18 Joel Franco Guzmán wrote: > > 1. 128M memory OK, but with 192M the sound card generate a noise while > > use the DSP. > .. > > the problem: The sound card generates a toc.. toc.. toc .. toc...while > > playing a sound using the DSP of the soundcard. Two "tocs"/sec > > aproxiumadetely. > > > > . > I have noticed something similar. If I start gqmpeg from the command line > in > a terminal (rxvt), sounds fine. If I start it from the icon in the gnome > panel, it makes that 'toc toc' noise you describe. > (I know it sounds strange, but real...) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 128M memory OK, but with 192M sound card es1391 trouble
You're probably just hearing electrical noise from the memory buss; try moving the 128 stick to the slot you put the 64 in (if you can) and run that way -- you'll probably hear it there too. I get something similiar to this with my SB Live (!... damn marketroids) on a BP6 with 192MB as well. In my case, it's not during DSP use per se, but during memory activity. Try dragging a window around in X and listen for buzzing. My guess is that JA's console player doesn't move around as much memory as the gnome one (imagine that), therefore produces less memory noise. -- /jbm, but you can call me Josh. Really, you can. "car. snow. slippery. wheee. dead josh. car slipped on ice." -- Manda explaining my purchase of kitty litter On Wed, 17 Jan 2001 17:25:51 J . A . Magallon wrote: On 2001.01.18 Joel Franco Guzmn wrote: 1. 128M memory OK, but with 192M the sound card generate a noise while use the DSP. .. the problem: The sound card generates a toc.. toc.. toc .. toc...while playing a sound using the DSP of the soundcard. Two "tocs"/sec aproxiumadetely. . I have noticed something similar. If I start gqmpeg from the command line in a terminal (rxvt), sounds fine. If I start it from the icon in the gnome panel, it makes that 'toc toc' noise you describe. (I know it sounds strange, but real...) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
