FVWM: I want to send in a question about something, and the mail registration system completely weirds me out.
So, do I have to register, or not? What if as far as I know my mail is coming neither by POP or IMAP, but by SMTP? What if my mail interface of choice is pine on my office machine, even if I am connected to it from the house on a Sunday? Anyway, if any human being is able to read this without it being automatically bounced, then please answer and I will ask my question! If you read this and answer, thanks! Theodore Kilgore
Re: FVWM: I want to send in a question about something, and the mail registration system completely weirds me out.
On Sun, 4 May 2008, Dan Espen wrote: <[EMAIL PROTECTED]> writes: FVWM: I want to send in a question about something, and the mail = registration system completely weirds me out. So, do I have to register, or not? What if as far as I know my mail is coming neither by POP or IMAP, but = by SMTP? What if my mail interface of choice is pine on my office = machine, even if I am connected to it from the house on a Sunday? Anyway, if any human being is able to read this without it being automatically bounced, then please answer and I will ask my = question! If you read this and answer, thanks! Theodore Kilgore You don't have to subscribe. You can just send email to [EMAIL PROTECTED] We'll copy you in any reply. But plain text is preferred, not HTML. -- Dan Espen E-mail: [EMAIL PROTECTED] Thanks. Incidentally, I have no idea how that you got a mail which is in html because I never use html for my mail and actually am one of those guys who believes that mail is supposed to be in ASCII. Tell me if you get this answer in HTML which is typed in text and if so we can both be weirded out! Hang on for a while. Since I did not get the mail bounced I was actually typing up a description of my problem and will send it in a few minutes. Theodore Kilgore
FVWM: My previous mail seems not to have bounced, so here is the problem
Incidentally, I am not a member of this list, so please reply to or copy to me in answering, thanks. First, as to the mail problem: It obviously arises because I do not use web-based mail and find it abhorrent. Right now, I am logged in via an ssh session from my home computer to my office computer, which is a mail server, and over there I am running sendmail and using pine to do my mail business. However, the issue arose because 1. I prefer that mail from outside, especially from mailing lists, comes through the main university mail system, thus, @auburn.edu. One reason for this is that my office machine is otherwise a single point of failure in my mail service. If it went down (which occasionally happens even to the best of systems) then I would not get mail until it is fixed. 2. Mail is automatically forwarded (via smtp, not pop or imap) to banach.math.auburn.edu (my own office machine) and that is where I actually do all of my mail business. 3. I assumed that I need to register myself and would need a login and password. Nothing came up but a series of amazing questions that have nothing to do with my mail setup, at all and therefore in context were complete nonsense. So I killed all of that and sent a plain text message. Then I read again that I only have to send a "subscribe" message. Trusting people, you are. In this age, that was totally unsuspected and thus was another thing that threw me off stride. The problem concerns permissions or transfer of key mappings in X. Specifically, if I start up X with fvwm2 as my preferred window manager and open an xterm as a user, then everything is fine. If I then at the command line in the xterm type the command "su" and provide the root password, then not everything works the same. The problem shows up in particular if I run Midnight Commander in the xterm. In that case the Alt key does something different. As you probably know, there are a lot of shortcut keystrokes in Midnight Commander. For example Alt-s will allow a downward directory search in a panel in MC. And Alt-Enter will bring down a filename to the command line which is below the two panels. Now, as I said, these key combinations work perfectly well in the xterm if one is the user who started the X session. But if one has done the su command to do some things as root inside of the same window, then Alt-s for example prints a Hungarian-style accented o (sorry, not reproducible here) on the command line instead of doing what it is supposed to do. Also, it seems that the things which the Alt key should be doing inside of MC get mapped over to the Cntrl key instead. Thus, Alt-s -> Cntrl-s seems to work, and Alt-Enter -> Cntrl-Enter does seem to work, too. This is an annoying transformation, of course, but worse than that is, it also disables some of the key combinations which work with the Alt key because those Cntrl-(same key) can mean something entirely different and that meaning is the one which gets used instead. More details, based upon further experiments: The same problem occurs if one starts up an unadorned X with just the one window in the upper left. The same problem occurs if I start fvwm2 and then switch over to KDE (I do not know if you have configured the shutdown menu to do that, but I have done so locally, quite some time ago in addition to the default menu choices which used to come with fvwm2). The same problem does *not* occur if one starts KDE from the command line. Namely, what happens then is I start KDE, open a window, and all is good. Then I do su in the window, enter the root password, get a root shell, and type mc. Then all is still good and the keys are performing as they should. My system? I am running Slackware-current which is at this moment equal to Slackware 12.1, with a lot of locally installed software. The fvwm is version 2.4.20, and the X stuff is something like 7.2.x IIRC. Now, the above sequence indicates that what may be happening is a bug in X. So I do not say that ipso facto this is a bug in fwwm2. That would depend to some extent on what the X people think about this, I would guess. They might believe that what they have done is not a bug but a feature, for example. I have no way to know. Either way that would come out, is this problem a previously known problem, or not? Also it seems that somehow kde has avoided this glitch somehow even though it is present at the lower level, somehow, in the X server and its permissions, its keymaps, or whatever. And fvwm2 seems at this point not to have avoided the problem, perhaps because nobody else tries to do things the way that I do in my normal course of work and thus the problem did not even come up for those individuals. If you think this problem is cured in 2.4.25, I am glad to try it. But I bet it is not. The problem is as I said one of those weird problems that I bet nobody was thinking of. Unless the X people were thinking t
Re: FVWM: I want to send in a question about something, and the mail registration system completely weirds me out.
On Sun, 4 May 2008, Dan Espen wrote: Damn, I'm behind a corporate Exchange Server which seems to have changed recently to converting everything it sees to HTML. How embarrassing. My sympathy. That is one of the advantages of working in a large university, I suppose. First, it is quite impossible for the IT people to impose a monolithic structure on us, because some of us were here first. Therefore, they know better than to try. They are pretty nice people, really, and I consider them good to work with. Also, I am in a department (mathematics) which is a local stronghold of Linux/Mac/Sun users and we do sometimes band together to pound the table and defend our interests. Therefore, the actual arrangement is: 1. Incoming mail to auburn.edu by default goes to a Groupwise server. 2. For those of us who really do not like that, there are designated local servers, such as one in the mathematics department which runs either on Solaris or Linux. Any mail to me at auburn.edu actually goes there, a copy is kept, and the mail is forwarded to my own mailserver. 3. So long as I am not having some kind of hardware problem, I just go over to the local departmental mail server periodically and delete everything, because I already got it and dealt with it anyway. 4. 99% of my interaction with mail is on a machine completely under my own control. Probably if I wanted to do things this way starting from now, it would not be liked. But I have been doing it this way for over ten years. Nope, no HTML converter on my incoming or outgoing mail. Meanwhile, have you read the post about my problem? Nice one, isn't it? One of those real brain teasers, to figure out at just what level and in which piece of software the problem is. Theodore Kilgore
Re: FVWM: My previous mail seems not to have bounced, so here is the problem
On Sun, 4 May 2008, Thomas Dickey wrote: On Sun, 4 May 2008, Thomas Adam wrote: On 04/05/2008, [EMAIL PROTECTED] [...] If you think this problem is cured in 2.4.25, I am glad to try it. But I bet it is not. The problem is as I said one of those weird problems that I But this doesn't have anything to do with FVWM. As I said, it happens with FVWM but cannot be repeated with KDE. This implies that FVWM and KDE are doing something differently. It also happens if one starts a "bare" X session. You know, the default which is done if one has no window manager at all. Just one xterm open and nothing else. From this I would conclude -- FVWM is doing the same default settings as the "bare" X, at least in this regard. This may be the "right" behavior, and there may be nothing "wrong" in this behavior at all. -- KDE is doing something else, which changes those default settings. This could conceivably be the "wrong" behavior on the part of KDE. In that case it manages to bypass the problem, somehow. Therefore, it does have "something" to do with FVWM. I did not say it is a bug in FVWM. OK, I am not using Slackware, but neither can I reproduce it, and I can't say I am surprised. There is nothing inherently weird in starting a termina, typing in su and then for it to mangle your bindings. It's -possible- it's something to do with XTerm, such as settings for its resource for thing like: eightBitInput eightBitControl And you perhaps not having set: XTerm*metaSendsEscape: true In your ~/.Xdefaults --- but this would explain really why you see this when you su. Hmmm. I looked now all over the system in all reasonable places for an Xdefaults file, found none. I also have no $HOME/.Xdefaults file at all. This is what man X has to say about such things: "XENVIRONMENT This must point to a file containing X resources. The default is $HOME/.Xdefaults-. Unlike /usr/lib/X11/Xresources, it is consulted each time an X application starts. " in which it seems that the last sentence is most relevant, here. Actually, this seems to have fixed the problem. I have done the following steps: 1. created a file called .Xdefaults and put in it the one line XTerm*metaSendsEscape: true and then 2. Exited from X and restarted, then run the same test. At this point the Alt key is doing right. That would be a reasonable possibility if he started a new xterm after doing su, I did not. And that is not what the man page says, it seems. but I don't see that in the description (it sounds as if he's running in the same xterm). That is right. It is the same xterm. There is a control sequence in xterm which can change this mode, but I'd be surprised if mc is using it. I don't believe so. Perhaps root's $TERM is set differently - or $TERMINFO and/or $TERMINFO_DIRS are set. It's not unusual for root's login scripts to set $TERM In the window in which one has performed su, the command echo $TERM produces the response xterm Clearly I could check the other two items. But it seems that the problem is now cured. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net Thanks for the suggestions. One of them worked. Also thanks for my question being answered promptly, and with courtesy. If you come to ask questions about a USB digital camera, I will try to act the same. I do agree that the problem is not with fvwm. Still, there is the issue that KDE manages to avoid choking on the same problem. Therefore, I would not go so far as to say that it has "nothing to do with FVWM." I do not think I would have that point of view if I were involved with your project. I am not involved there. I know that. But I am very much involved in the Gphoto project. I do quite a bit of support for cameras, especially those cheap ones at places like Wal-Mart which come with proprietary communication protocols and are advertised for Windows only. So if you are having a problem with one of those things, you and I will switch hats. You will be coming to some place like the gphoto-users or gphoto-devel list, and I may be the one who works with you to support your camera. If some kind of funny business is happening at some basic level and falls into my purview because it deals with the software that I wrote, it does bother me. If I were in your shoes, I would truly try to figure out some way how to bypass the problem as KDE does. I would do that because a problem like this is one of those kinds of little things that can drive a user nuts. And few of them are going to be as patient as I am in trying to hunt the solution. As much as time permits, I am quite willing to help you test a solution to this, which could be somehow be packaged with or incorporated into the FVWM release, so that a user is not faced with the need to chase down such a stupid problem in the future. Cheers, Theodore Kilgore
Re: FVWM: My previous mail seems not to have bounced, so here is the problem
On Mon, 5 May 2008, Thomas Dickey wrote: On Mon, 5 May 2008, Sergey Vlasov wrote: On Sun, 4 May 2008 18:06:00 -0400 (EDT) Thomas Dickey wrote: There is a control sequence in xterm which can change this mode, but I'd be surprised if mc is using it. Recent libreadline (used by bash) sends this - you can observe it with 'strace -e write bash': write(2, "\33[?1034h", 8) = 8 I did recall that - hadn't related it to mc... When xterm receives this sequence, it switches to "8-bit mode" (*VT100.eightBitInput: true), where the Meta key sets the 0x80 bit of input characters instead of adding the ESC prefix. The "konsole" terminal emulator from KDE just ignores this sequence and continues to send the ESC prefix for Meta. yes - konsole doesn't implement the meta feature with or without the control sequence. Apparently this sequence comes from the 'smm' string in the terminfo database, which was added somewhere between the 211 and 222 releases of xterm (I do not see an explanation for this in xterm.log.html). It's in #216, added for completeness (since I'd added the control sequence at that point). I recall some discussion regarding readline, which turns on the feature if it exists (and commented that readline should have made it optional). There does not seem to be a way to disable this behavior through the libreadline config file (~/.inputrc). A possible workaround in ~/.Xresources: *VT100.altIsNotMeta:true *VT100.altSendsEscape: true *VT100.metaSendsEscape: true *VT100.Translations:#override \ Meta: insert-seven-bit() Setting just metaSendsEscape: true is not enough in the common case when Meta and Alt are the same key - apparently in this case xterm treats this modifier key as Alt instead of Meta, even though the Meta translations work for it; and the code in input.c:Input() does not reset the "eightbit" flag in the alt_sends_esc case, like it does for meta_sends_esc, therefore the translation override is needed to prevent setting of the 0x80 bit in addition to the ESC prefix. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net Thanks for all the attention to the keycodes problem. On this end, I do not have time to think deeply or to investigate more deeply until I get a stack of differential equations finals and then another stack of linear algebra finals graded (should be doing that right now, but this is more pleasant). However, this is what it looks like from here, reading the discussion in this thread: 1. apparently X has changed some of its defaults. Should they have done that? That is a very good question and I do not know the answer to things which are outside the scope of my work. 2. apparently KDE in reaction has changed some of its defaults, too, or has always coded their terminal support this way, possibly anticipating a problem which now has happened but the lightning struck somewhere else. Should they have taken this approach? That is a good question, too, is it not? 3. The MC mailing list (where I reported the same problem) thought it was not their issue. I can understand their attitude, but as I said in reaction to something that looked similar here, too, I do not think that this is the most constructive attitude which is possible. 4. FVWM has up to this point said it is not exactly an FVWM problem, either. 5. Me: It looks from this side as though there are a bunch of developers who are doing projects that in fact are interdependent and each relies on the other one doing things a certain way. But then project X changes the way that something was done, and projects Y and Z go off in some other direction or do not notice what project X did, which changes the outcome of what they are doing. Quite rightly, nobody would say that here is a bug in my project. Quite rightly, nobody would say that there is a bug in that other project, either, which is causing the problem. That would be a very irresponsible attitude. Note that I don't share that attitude, either. However, there is in fact a problem, and I do not believe that things like this can be straightened out unless there is more contact between the various groups of developers. for, the effect is a negative and frustrating user experience which I would think that none of us want. Our software is supposed to work, and smoothly, too. We are not supposed to let things like that happen. Leave that kind of screwups to the Great Monopolist, whose software does not seem to need to be attractive and pleasing. Solutions? My ad hoc solution was to create an .Xdefaults file which changes the default behavior of xterm. Ought this to be the universal solution? Not sure about that. Why did X use those new keyboard mappings? Could it be that the "funny-looking" characters ought to be printed, because some people want or need them? So this "solution" turns that off. As my wife would say, w
FVWM: Some items on a wish list
Hi. After some recent experiences setting up an old laptop, I noticed the following, which some might regard as shortcomings. If anyone who has more knowledge about how the internals of fvwm are put together would like to do a little hand-holding, then I am quite willing (and probably able, though not familiar with the code organization of fvwm, as yet) to try to help out. A list of two items follows: 1. Apparently, there is no support for PNG icons. If I want to do something like borrow an icon from somewhere, or if a piece of software comes with its own PNG icon in the package, then I have to convert the icon to XPM format in order to use it. For me, it is not a big deal to do the conversion, but perhaps it would be nice if PNG format were recognized, too? 2. For a laptop, there are such things as battery and temperature sensors. Fancy environments such as KDE have support for things like indicators for the battery. I wonder how hard it would be to provide this for fvwm? Actually, I conjecture that this would not require a deep dive into the code at all, but rather the hooking up of some already-existing program into a display "icon" something like the load indicator, which already has been done a long time ago. But I wonder if anyone has done this, or thought of it? Theodore Kilgore
Re: FVWM: Some items on a wish list
On Wed, 6 Aug 2008, Thomas Adam wrote: 2008/8/6 <[EMAIL PROTECTED]>: The laptop is running, over on the other side of the room, because I have been involved in doing some security upgrades on it, while dealing with e-mail over here. So I just went over there and ran "sensors" and it says there are none. There is something called "smbus" connected to the PIIX4 chipset, but it is not at all obvious what it does. What does dmidecode tell you? What's your kernel version? dmidecode? It tells me lots of things. Specifically, what should one look for? It does have Handle 0x1600, DMI type 22, 26 bytes Portable Battery Location: Left Module Bay Manufacturer: Panasonic Name: 4460 Design Capacity: 66010 mWh Design Voltage: 14800 mV SBDS Version: 1.0 Maximum Error: 1% SBDS Serial Number: 0378 SBDS Manufacture Date: 2007-06-06 SBDS Chemistry: LION OEM-specific Information: 0x0001 and a similar section about a temperature sensor. But neither of these appear to be actually reporting real-time data. Kernel is 2.6.24.4, locally compiled. I _do_ finally find the information, though: There is a directory /proc/acpi and in it there are relevant subdirectories, one of them named battery and the other named thermal_zone. Now, the subdirectory battery/BAT0 has in it several files, for example "state" which has in it present: yes capacity state: ok charging state: charging present rate:29069 mW remaining capacity: 69190 mWh present voltage: 16755 mV The BIOS has a screen for display of battery status, so presumably this information needs to be read by some app, and it seems that "sensors" is not doing it. By this point this has *nothing* to do with FVWM, so you will want to look elsewhere. Well, at this point it does seem there is some information after all. So the question is how to use it. -- Thomas Adam Theodore Kilgore
Re: FVWM: Some items on a wish list
On Wed, 6 Aug 2008, Robert Heller wrote:
At Wed, 6 Aug 2008 17:32:34 -0500 (CDT) [EMAIL PROTECTED] wrote:
Thanks, something else to look into.
Now, however, a problem, just discovered:
The laptop is running, over on the other side of the room, because I have
been involved in doing some security upgrades on it, while dealing with
e-mail over here. So I just went over there and ran "sensors" and it says
there are none. There is something called "smbus" connected to the PIIX4
chipset, but it is not at all obvious what it does.
The BIOS has a screen for display of battery status, so presumably this
information needs to be read by some app, and it seems that "sensors" is
not doing it.
Battery status is handled by either APM or APCI, depending on laptop
vintage and/or BIOS settings. Older laptops used APM and newer ones use
APCI. Modern kernels detect which. If APM, you need apmd and (x)apm to
check battery status, if APCI, the kernel creates some directories under
/proc/acpi that contain text 'files' that contain the state of the power
plug (/proc/acpi/ac_adapter/AC/state) and the batteries
/proc/acpi/battery/*/{info,state}.
The sensors are handled by lm_sensor -- these include stuff like power
supply voltages, CPU temp, and CPU fan speed.
I know.
"smbus" also includes
reading some proms and stuff -- can be used to identify things like
DIMMS and such like.
Is there, then, a command called "smbus"?
You can try running sensors-detect (as root) and
see if it finds the sensors. You might need to load some kernel modules
to get this going.
I did. Some excerpts from the output:
To continue, we need module `i2c-dev' to be loaded.
Do you want to load `i2c-dev' now? (YES/no): YES
Module loaded successfully.
We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.
Next adapter: SMBus PIIX4 adapter at 0840 (i2c-0)
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...No
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): YES
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors...No
AMD K8 thermal sensors... No
AMD K10 thermal sensors... No
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Sorry, no sensors were detected.
Either your sensors are not supported, or they are connected to an
I2C or SMBus adapter that is not supported. See doc/FAQ,
doc/lm_sensors-FAQ.html or http: et cetera.
OTOH the commanbd i2cdetect gives
[EMAIL PROTECTED]:/usr/src/linux# i2cdetect
Error: No i2c-bus specified!
Syntax: i2cdetect [-y] [-a] [-q|-r] I2CBUS [FIRST LAST]
i2cdetect -F I2CBUS
i2cdetect -l
i2cdetect -V
I2CBUS is an integer
With -a, probe all addresses (NOT RECOMMENDED)
With -q, uses only quick write commands for probing (NOT RECOMMENDED)
With -r, uses only read byte commands for probing (NOT RECOMMENDED)
If provided, FIRST and LAST limit the probing range.
With -l, lists installed busses only
Installed I2C busses:
i2c-0 smbus SMBus PIIX4 adapter at 0840
[EMAIL PROTECTED]:/usr/src/linux#
I have tried running KDE on the laptop, and it does then display a battery
icon. But at this point it is not obvious to me how KDE is getting the
information out of the BIOS.
See above.
Any ideas what might be going on down at this, more basic level?
Apparently, this seems to be turning into a major engineering project. :/
Someone already has solved it...
Good thing, too.
I think the problem is localized now, though. The acpi stuff seems to be
working and reporting information. So the question is now the same as in
my previous reply post: how to use that information and to get it onto an
fvwm button?
Theodore Kilgore
