[ltp] seeking love for Thinkpad "Convertible" Tablet-PC
Wed, 10 Jul 2013 12:52:00 -0500
On Wed, 2013-07-10 at 12:01 +0200,
> Message: 2
> Date: Tue, 09 Jul 2013 15:19:12 +0200
> From: Florian Reitmeir <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: [ltp] seeking love for Thinkpad "Convertible" Tablet-PC
> Reply-To: firstname.lastname@example.org
> > There are all sorts of things that work very well under the Windows-7
> > boot, but that Linux continues to choke on. Both IBM and Lenovo have
> > traditionally been Linux friendly so I don't understand why some of
> > these things are not stone-cold resolved.
> Because people like you, which own the hardware, are not fixing the
> problems. Most people can not help you, just because they do not have
> this hardware. And most people in der OSS World, don't buy this hardware
> because nobody else has it..
> just beginn to fix things, it will make the world better for you and others.
> Florian Reitmeir
> E-Mail: email@example.com
> Tel: +43 650 2661660
While I appreciate your sentiment and agree that more folks involved
makes things better for everyone. Further, there are workstations and
components on the edges of the Linux hardware compatibility list. With
this in mind, what you ask is not simple to accomplish.
I've searched and read all sorts of threads and blogs about Linux of all
stripes on the Thinkpad tablets. Some folks say that everything "just
works". Others have mountains of grief. Many, like me, have lots of
success and a few spots of trouble. While we have the same hardware --
plus or minus manufacturing batch tweaks -- why these differences in
experience? Simply discovering the list of differences suitable for
fault analysis is a major undertaking.
Not long ago, I spent almost six months of evenings and weekends trying
to gather enough information that I could explore my troubles with
suspend-to-RAM(sleep) and suspend-to-Disk(hibernate). I had all sorts of
documents and folders filled with source code. I subscribed to developer
listserv and forum opportunities. Yet I was not able to gather much
additional knowledge and understanding.
I'm a technical guy. I've written *nix device drivers. I've built
embedded systems around the Linux kernel. I've even built kernels for
processors long ago. The current generation of event-driven system
start-up (upstart) and load-on-demand kernel modules present a huge set
of "moving parts" that require an enormous investment in learning just
to read the code, much less do anything with it.
In the case of 'suspend' there are some straight forward analytical
** What was saved as system state? Was it saved correctly? Where is it
saved? How does one read and interpret it?
** What looked for information during recovery?
** Did they look in the right place(es)?
** Did they find what they were looking for?
** Was the found data correctly the data needed?
** Did they deploy the recovery data correctly?
If recovery fails, often one must cold-restart the workstation.
** Where are any artifacts of the state-save or recovery attempt?
** If you find artifacts, how do you interpret what is there or
missing? How would you know something is missing?
If I sound defensive, maybe I am. Certainly, I'm frustrated. Resorting
to reading kernel source code to answer any of the above questions seems
excessive. I don't need knowledge of the geology of iron and aluminum
ore and metallurgy to correct a car engine that is running rough.
~~~ 8d;-/ Dan