Ulrich Drepper wrote:
Define latest. It should work in 2.6.90-17.
Indeed, it does. I was still using 2.6.90-16, from two days ago.
What was the fix? I think we'll need to backport the patch to F7's
glibc for fork the package off in OLPC-2.
--
\___/
|___| Bernardo Innocenti -
Ulrich Drepper wrote:
Bernardo Innocenti wrote:
What was the fix? I think we'll need to backport the patch to F7's
glibc for fork the package off in OLPC-2.
Lot's of changes in at least three completely different places. Just
use the F8 glibc, it can only be better.
Thanks!
--
\___/
(adding devel@ to cc)
Mitch Bradley wrote:
Jim Gettys wrote:
What are the olpc vs. olpc2 variants?
The way that I understand it based on Bernie's IRC explanation, is that
these are different usage models based on how you interpret one of the keys.
It is not a property of the keyboard
On Sat, 2007-10-06 at 16:33 -0400, Bernardo Innocenti wrote:
(adding devel@ to cc)
Mitch Bradley wrote:
Jim Gettys wrote:
What are the olpc vs. olpc2 variants?
The way that I understand it based on Bernie's IRC explanation, is that
these are different usage models based on how you
Hello lists,
Personally, I have not yet had an opportunity to test the different
components in the Helix project. As such, most of what I know comes
from Wikipedia.
In Wikipedia, it is stated that the Helix DNA Client supports Vorbis
and Theora, but apparently, not Speex. Is it this true? How
I've been chatting with Sergey Udaltsov about defining keyboard better,
so we might introduce new keyboards without having to revise firmware or
often even the software for new keyboard types we want to introduce. Right now,
we have
an unholy mess left from before B1, where we divine the keyboard
Jim's proposal solves the X problem, and I think we should adopt it.
We also have the problem of letting OFW and the Linux kernel know enough
about the keyboard so developers can type US ASCII , which is the common
subset that is sufficient for managing diagnostics, booting, and
installation
Mitch Bradley wrote:
One solution would be to include a lot of keymaps in OFW and select one
based on the new KL tag. However, I'm not keen on having to carry
around a lot of keymaps in the ROM, and extend that list from time to time.
There's also a trivial, good enough solution to the
On Oct 7, 2007, at 0:08 , Bernardo Innocenti wrote:
Mitch Bradley wrote:
One solution would be to include a lot of keymaps in OFW and
select one
based on the new KL tag. However, I'm not keen on having to carry
around a lot of keymaps in the ROM, and extend that list from time
to
Bert Freudenberg wrote:
I disagree. It's a major hassle if the keys you press do not do
what's printed on them. Simply assuming a US layout when the machine
can know quite well what keyboard is attached is unacceptable. It's a
shortcoming of external keyboards that they do not
Back to the original question, in case it is needed:
Keyboard Layout KM KLKVComment
USInternational_Keyboard olpc usolpc
OLPC_Argentina_Keyboard olpc esolpc (Spanish)
OLPC_Brasil_Keyboard olpc brolpc
Bernardo Innocenti wrote:
Mitch Bradley wrote:
One solution would be to include a lot of keymaps in OFW and select one
based on the new KL tag. However, I'm not keen on having to carry
around a lot of keymaps in the ROM, and extend that list from time to time.
There's also a
Re: New manufacturing data flags for keyboards (2nd draft).
Keyboard Layout KMKL KV Comment
USInternational_Keyboard olpc us olpc
OLPC_Argentina_Keyboard olpc es olpc(Spanish)
OLPC_Brasil_Keyboard olpc br olpc(Portuguese)
13 matches
Mail list logo
