Problems? See this thread at archive.org.
I started writing this as a reply on another thread but then decided to start a new one so everyone can benefit
(and don't be misguided by the title, I still think it's a GREAT machine and am still discovering it)
Pitabred: are you running some distro of Linux on a Hel80?
I have been trying the latest Mandriva and a beta of Kubuntu. Both look great in many respects and both detect a lot of the hardware correctly. (I have moderate hope of making the webcam work and almost none about the fingerprint scanner, but I don't care much).
The main problem, though, is the ACPI implementation of the BIOS. I'm upgraded to the latest 110B but nothing changed. In particular, I can't detect CPU temperature (and fan control but maybe this would be stretching my luck).
The HEL80 BIOS imlpementation of ACPI seems to be quite non-standard, if not buggy (I had a couple of PCI error messages when booting the machine, even before loading the OS)
In Linux I've tried the latest kernels (2.6.18) and the latest lm_sensors. The sensors-detect utility went through all the process of chipset detection and failed to get any information about temperature and other ACPI stuff.
Another problem which may be related to te BIOS is that I have no way to access the hard drive SMART information. So the the SATA BIOS implementation has some non-standard issues as well.
Now, on Windows I've tried Everest and it recognized everything. I could read CPU temperatures (around 30 celcius when idle, quite cool!!!!!), and hard drive around 42-45 which is much better than my old system, especially if you consider my HEL80 has a 7200rpm drive while my old Sager has a 5400rpm (and temperatures reaching 50 degrees or more). Of course, this is after installing the Chipset drivers that come on the CD.
Having CPU temperatue readings in Linux is not extremely important, especially now that I know the normal temperatures are low. But I had to install Windows in order to test that. Something I had been resisting
I'm, interested to share Linux experiences with the forum.
Maybe a list of what works out of the box and what doesn't, under what distros, and what workarounds you have found.
-
-
that's a very initial list
With respect to the media & Fn keys, I've had mixed success by changing the keyboard layouts under KDE. Kubuntu immediately recognized the mute and volume keys. Also the media keys on the left seem to start Amarok. LCD brightness seems to be down level in the BIOS or something so they always work. If you look in /var/log/messages, when you press the quick access 1 and 2 keys, there's a log there with the unrecognized key codes, so I'm sure they can be mapped unto something after reading some man pages.
I'm mostly using Mandriva as the Kubuntu live disc (beta) looked magnificent but did not want to install (the install process stopped when asking for timezoneinfo).
If I have time, I'll try to do a better grid/table of what works and doesn't and the workarounds under the different distros. -
First off, I don't have my Compal yet. Got the Core 2 Duo, etc., so it should hopefully arrive next week
And I'm getting an HGL-30, not an HEL-80.
Buggy ACPI is common. Welcome to Linux. It's gotten much better over the years. But the driver still has a number of custom dsdt tables and workarounds hard-coded into it because of so many buggy ACPI implementations, primarily in laptops. Manufacturers don't test them very well, and they do more "custom" things in laptops.
But I'm finding it strange that you can't get SMART info on your hard disks.
"sudo smartctl -H /dev/hda" doesn't work?
What you can do with mapping keycodes is look at the "xmodmap" command, should get you started.
What layouts did you change in KDE? I'm planning on using Kubuntu, so if you can give me a quick jump on things I'd want to config, I'd be much obliged I'm planning on keeping track of what I have to do on my machine, and if I write any custom scripts or anything I'll make sure I post them here in the forum.
-
Well, right now I'm under KDE and the keyboard layout I'm using is "Hewlett-Packard Pavilion ZT11xx". Why? I don't know
I've tried most of them and none recognizes ALL the keys but this one recognizes the most important ones i guess.
What works: (HEL80, Mandriva 2007, KDE 3.5.4)
Fn-F4 and Fn-F5, for LCD brightness, which as I said, are coded in a lower level BIOS so they always work even in the POST screen
All the media Fn keys (Fn-F6 to Fn-F1, which are recognized correctly as XF86AudioMute, VolumeUp, VolumeDown, AudioPlay, AudioStop, AudioPrev, AudioNext respectively).
Fn-ScrlLk and Fn-PrtSc also worl. Fn-SysReq I'm not sure...
The HEL80 has extra media keys on the left side of the keyboard.
The first one from the top, "Mode On/Off", is not recognized in any way that I see so far, not even error messages in /var/log/messages.
The other three are recognized as XF86AudioNext, AudioPlay and AudioPrev which matches the icons on the left (on the right they have icons for +, stop, -).
This machine also has quick access buttons on the top. The email button fires the email application (KMail), recognized as XF86Mail, the web button is seen as XF86WWW but I guess is not mapped to anything which is easy to solve.
As for the "1" and "2' keys, they are not immediately recognized in this keyboard layout (don't remember other layouts), but /var/log/messages says:
atkbd.c: Unknown key pressed (translated set 2, code 0xf4 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e074 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xf4 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e074 <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0xf3 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e073 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xf3 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e073 <keycode>' to make it known.
So I guess they could be made to work for something useful. with a little keyboard configuration.
As for the first three Fn-Fn keys (Fn-F1 has a half moon I guess for suspend, Fn2 looks like a WiFi icon, and Fn-F3 looks like LCD/VGA switching) they don't do anything at all in any keyboard layout...
I guess that covers all the special keys on this laptop under my very constrained domain of tests ;-) -
But let me add some stuff:
=== nVidia 7600 Support ===
In Mandriva One, the 3D driver installed automagically so I had the 3D Compiz desktop (GLX mode) with the flying cubes, wobbling windows, and real transparencies that you may have seen on the web. I also had some success with the new nVidia beta drivers (9625, I think), that I installed under a kernel-multimedia-laptop-smp.2.6.17.BLABLABLA. Mandriva gave me the option to use AIGLX instead,but I couldm't get Compiz to start, getting the same old (new!) KDE. On the good side, the new driver had an nvidia-settings utility in which dynamic TwinView finally worked withtout having to restart X in order to get different modes (LCD only, LCD+external VGA in clone mode, LCD+external VGA in extended desktop mode). Still not as flexible as Windows for the easy stuff, but getting there. And if you are into editing xorg.conf for a whole weekend, you'll get a fine level of configuration that you may not have in Windows.
=== CD Burning ===
I burned CD's with the included K3B in Mandriva One. It worked well, except that it was much slower than I expected, averaging no more than 10X speed and the device buffer getting dangerously to 0% many times.
I'm not sure whether the problem lies in:
* The CD drive itself
* The BIOS
* Linux's approach to interfacing witht the BIOS and its drivers for cdrom
* K3B and it's underlying libraries (cdrecord I think)
* The CD media itself, although I've used these same CD-R's from the same package in Nero under Windows and I've burned at 16X (that's how I burned the Mandriva One CD).
This is my first time ever burning CD's in Linux so I'll have to experiment more.
An md5 check of the media after burning came exactly the same as the original ISO's, for the 5 CD's I burned, so nothing got corrupted, just slow.
=== Suspension & Hibernation ===
Again, in the latest mandriva. Suspension worked perfectly after enabling ACPI helper from the KLaptop application. I can suspend from the KLaptop context menu and I configured to suspend when closing the LCD lid. The Fn button to suspend didn't work as I explained above. Not only suspension worked fine, but resuming also!!!! That's the important part
In the pase, with older distros and older machines I had trouble resuming, sometimes Linux rebooting completely and even getting into a rebooting loop.
For hibernation, I downloaded the hibernate package/RPM which uses some new suspend2 features in the kernel to help with hibernating. But I never got around configuring it (you have to pass a suspend2= parameter to the kernel, I guess telling it where the hibernate file is.) I'll try it when I go back to playing with Linux. -
I did it again, presssed the wrong button while on quick reply...
I was saying that XGL uses a dirty trick, creating a full screen OpenGL and starting an new server on it, assigning it X screen :93
If you do (in a shell) export DISPLAY=:0 then you can start new gl applications from that shell, but they may be pbscured under the full screen :93
But there a key combo (Alt-11 ??) that will give borders to your full screen and you can move it around and reveal the :0 under it
Anyway, AIGLX is supposed to work without all these dirty tricks but only a few chipsets support it so far. The new nVidia drivers (beta) supposedly do -
Still alot of resources for eye candy =P...
Either way, I have it installed just for grins
-
Does anyone know the difference between Beryl and Compiz here? From what I understand, Beryl is a fork of compiz...
Btw, is it easy to install compiz/Beryl on the HEL80? (So far it doesn't seem good)
-
-
I'm using Beryl. It works fine... though it does lock up fairly often
-
hey there,
I'm currently dual-booting my HEL80 with xp and a clean debian/etch, so far everything seems to be in working order
the things I did not get to work under debian are mostly what I expected:
- sensors are not detected (no thermal / fan speed info)
seems like this is normal for ENE using notebooks, just another company that forgets about its linux customers
- dial-up modem (agere hda winmodem) does not work
did not check extensively on this one, perhaps s.o. here has further informations?
- fingerprint sensor
well, I use it for fun under xp (which is a pure gaming platform), but would never do sensitive work with it. would be funny to get it working under linux tho.
- sd-card reader
same as with the sensors, this seems to be an ENE issue. this is probably the most annoying issue under linux.
so far, I'm in love with linux on my notebook.. so getting those tiny nitbits to work would be just great
have fun -
-
-
-
Unfortunately, I'm not. I'm off on a job, so I don't have access to my personal laptop until at least Friday
But thanks, I'll let you know as soon as I get into it. I've already imported a new splash graphic and changed some of that scripting, I figure I can't break too much else in it... hehehe
-
Thanks a lot Raleigh!
I'm the one who originated this thread.
I'll wait a few days until the latest Ubuntu is released, and I may also try the recently released Mandriva 2007.1 and the tmb kernels (2.6.20.something) to see if they fixed it although I doubt it.
A few questions though.. you seem to know a lot about these issues:
1) Your fix seems to be for BIOS Version 1.0, however the latest BIOS versions are something like 1.16 or 1.18... would it work the same?
2) I found somewhere an explanation of how to use a custom DSDT for some Suse version by beans of creating a new initrd.img and using some parameters.. no need to recompile kernel.. forgive me for the vagueness, I don't have the details here
Do you know anything about that?
3) The project ACPI at sourceforge.net seems to be a little.. I'd say.. abandoned.. not many recent updates and most tutorials and docs are from 2004-2005. Is it because the recent kernels are much better at ACPI so all these customizations are not needed as often?
4) Why is it that Windows has no trouble with all these ACPI stuff (no special drivers or anything needed) and the Linux Kernels suck at it?
Why is it that notebook makers implement the ACPI stuff in such non-standard ways? One would think that if they spend several millions in research&dev, they could invest a couple of weeks to write a good ACPI code....
5) How does the acpi.sf.net project relate to the lm_sensors project... is there some overlap? I spend a couple of months trying to find answers to my thermal_zone problems in Linux and didn't know what the most appropriate project was in order to ask.
6) Does the Kernel use some kind of hardware detection to know what ACPI/DSDT code to use?
7) Can your code be sent to the Kernel guys, or at least to the major distros so they include it? The HEL80 family is quite popular, especially among the most savvy computer users, the ones most prone to be using/wanting to use Linux.
enough for now
-
1) Your fix seems to be for BIOS Version 1.0, however the latest BIOS versions are something like 1.16 or 1.18... would it work the same?
Yes, you could use a 1.0 DSDT with a 1.18 Bios, although a later BIOS could
have some other fixes in its DSDT, so Id probably rework it for a new version
if the changelog suggests a ACPI fix of some sort.
2) I found somewhere an explanation of how to use a custom DSDT for some Suse version by beans of creating a new initrd.img and using some parameters.. no need to recompile kernel.. forgive me for the vagueness, I don't have the details here
Do you know anything about that?
I don't use inird.img as I always compile my own kernel, and compile in all the
drivers I need to boot with. To use a DSDT file, you need to be sure your
kernel is compiled to load a DSDT file from a particular location, mine is
/usr/src/dsdt.asl. Then, at the start of the kernels boot process, it will load
that file from the hard drive, parse it in place of the BIOS version, then
continue on the boot process.
3) The project ACPI at sourceforge.net seems to be a little.. I'd say.. abandoned.. not many recent updates and most tutorials and docs are from 2004-2005. Is it because the recent kernels are much better at ACPI so all these customizations are not needed as often?
Its the only solution to fixing missing thermal monitoring in a BIOS. I think
it is that most modern BIOS's are much better. For some reason Compal
chooses not to go out of their way to make a full featured BIOS.
4) Why is it that Windows has no trouble with all these ACPI stuff (no special drivers or anything needed) and the Linux Kernels suck at it?
Why is it that notebook makers implement the ACPI stuff in such non-standard ways? One would think that if they spend several millions in research&dev, they could invest a couple of weeks to write a good ACPI code....
I'm not sure Windows is so good at it, it just that Compal finds it easier
to make a special Windows only app for thermal monitoring by poking
the hardware directly, rather than follow the ACPI standard to create a
generic interface to their hardware.
5) How does the acpi.sf.net project relate to the lm_sensors project... is there some overlap? I spend a couple of months trying to find answers to my thermal_zone problems in Linux and didn't know what the most appropriate project was in order to ask.
6) Does the Kernel use some kind of hardware detection to know what ACPI/DSDT code to use?
The kernel reads the BIOS DSDT UNLESS you specify an external file. You
have to enable ACPI in the kernel in order for the DSDT to be parsed.
7) Can your code be sent to the Kernel guys, or at least to the major distros so they include it? The HEL80 family is quite popular, especially among the most savvy computer users, the ones most prone to be using/wanting to use Linux.
Not really, as the kernel by default just loads the BIOS DSDT table. Its really
not that common to make your own DSDT file and use it. Fortunately Intel
gave us the tools to hack our own fixes. Most savvy use should be able to
load an alternate DSDT file from the ACPI site.
I think a better option would be to hound Compal to incorporate my fixes
in their next BIOS release And we should hound them to stop slacking and
give their customers a quality BIOS, not one thats just adequate.
--Raliegh -
I missed one
5) How does the acpi.sf.net project relate to the lm_sensors project... is there some overlap? I spend a couple of months trying to find answers to my thermal_zone problems in Linux and didn't know what the most appropriate project was in order to ask.
In general. ACPI covers standard thermal/fan interfaces that are defined by
the BIOS's DSDT table. Lm_sensors is a group of drivers that interface to
the may brands of interface chips that mainboard manufacturers design
into their boards.
I spent several months too until one day, just for kicks, I decompiled my DSDT
to make sure there was thermal monitoring code was there. And it wasn't.
So by grabbing many DSDTs from the ACPI site, I followed the technique and
in one evening I managed to get my thermal monitor working.
After, I tried, unsuccessfully to add code to be able to control the fans
directly. I feel the HEL80 fans are controlled by hardware only.
--Raliegh -
Great! Very thorough in your answers
I'm going to try the new Kubuntu this afternoon...
Then I'll try to implement your fix -
-
-
ok.. it's more involved than I thought so I'll fix other issues first, like getting the nVidia drivers installed before I compile my custom kernel
thanks for the info anyway!
Linux on the new Compal machines and buggy BIOSes
Discussion in 'Other Manufacturers' started by barspi, Oct 6, 2006.
