Re: X0-4 (vivante) GPU driver development sponsoring

2013-06-26 Thread John Watlington

On Jun 26, 2013, at 9:21 AM, Christian Gmeiner wrote:

> I have heard that your X0-4 is powered by an Vivante GC1000 GPU. Cause of this
> fact I am looking for a partner to sponsor the development of
> etnaviv[1]. Together with the current maintainer we have a roadmap that looks 
> like this:

Unfortunately, I can't directly sponsor this project right now.
I have brought it to the attention of some people who might,
and can offer you hardware and help with testing the result.

Regards,
wad

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


X0-4 (vivante) GPU driver development sponsoring

2013-06-26 Thread Christian Gmeiner
Hi.

I have heard that your X0-4 is powered by an Vivante GC1000 GPU. Cause of this
fact I am looking for a partner to sponsor the development of
etnaviv[1]. Together
with the current maintainer we have a roadmap that looks like this:

- Mesa integration (3 weeks)
- GC2000 support - if not already done (2 weeks)
- implement context handling (3 weeks)
- Checking and fixing corner cases for the shader compiler (2 months)

2 months may be on the long side, Then again, testing with various
software and drilling down to the problem is
time-intensive, and chromium probably uses a challenging subset of OpenGL ES.
So it may be a safe estimate.

# at this point a mesa driver should be useable with Vivante's GPL
kernel driver and
# the imx-drm may could be used in combination of the xorg modesetting
driver to get
# a full blown desktop environment up and running.

This will be without 2D acceleration at this point. For optimal
performance, we may need very
basic 2D support to blit the final rendered image to the screen in a window, but
that's hard to say at this point.

- start the mesa-mainline process (depending on how many iterations
are needed ~ 1 Month)
- start thinking about the kernel side of the driver (v2 vs v4 kernel
interface) and begin
  with a kernel driver. (2 Months)
- adapt the current user space driver if needed. (x weeks)
- mainline the kernel side of the driver (depending on how many
iterations are needed ~ 1 Month)

# a full open source (kernel and userspace) is done, which is fully
integrated into the
# linux graphics stack.

After 4 months the user space driver is ready.
After 5 months the user space driver is mainlined.
After 8 months the kernel driver is ready.
After 9 months the kernel driver is mainlined.


What do you think?

[1] https://github.com/laanwj/etna_viv

thanks
--
Christian Gmeiner, MSc
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [OLPC New Zealand] Māori Macrons & olpc keyboard

2013-06-26 Thread Tom Parker

On 26/06/13 10:52, Walter Bender wrote:

The widget was broken until recently. Not sure my patches have landed
in any releases yet. But we should be able to make a layout that works
for both English and Maori without any end-user intervention. Will try
to get to it this week.


Attached is a patch to the output of xkbcomp on an XO-4 with mechanical 
keyboard. Sorry it's not in style of the files in /usr/share/X11/xkb, I 
still haven't been able to unravel how those files work. I think I can 
make an mi file that just has the changed lines, which layout should I 
use as a base? I'm guessing I might need to do something different for 
the membrane and mechanical keyboards?


What is the best way to modify the laptops? Copying modified output of 
xkbcomp to /usr/share/X11/xkb/symbols/mi and running


setxkbmap mi

does the trick, but setting the content of /home/olpc/.Xkbmap to mi does 
not make this the default after reboot.
--- orig.xkb	2013-06-26 09:28:21.770500621 +
+++ test.xkb	2013-06-26 09:28:07.050500619 +
@@ -1188,7 +1188,7 @@
 key  {
 type= "FOUR_LEVEL_ALPHABETIC",
 repeat= No,
-symbols[Group1]= [   e,   E,  oe,  OE ]
+symbols[Group1]= [   e,   E,   U0113,   U0112 ]
 };
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
@@ -1208,17 +1208,17 @@
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
 repeat= No,
-symbols[Group1]= [   u,   U,   U032D,   U032D ]
+symbols[Group1]= [   u,   U,   U016B,   U016A ]
 };
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
 repeat= No,
-symbols[Group1]= [   i,   I,   U032C,   U032C ]
+symbols[Group1]= [   i,   I,   U012B,   U012A ]
 };
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
 repeat= No,
-symbols[Group1]= [   o,   O,   U0323,   U0323 ]
+symbols[Group1]= [   o,   O,   U014D,   U014C ]
 };
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
@@ -1246,7 +1246,7 @@
 key  {
 type= "FOUR_LEVEL_ALPHABETIC",
 repeat= No,
-symbols[Group1]= [   a,   A,  ae,  AE ]
+symbols[Group1]= [   a,   A,   U0101,   U0100 ]
 };
 key  {
 type= "FOUR_LEVEL_SEMIALPHABETIC",
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [OLPC New Zealand] Māori Macrons & olpc keyboard

2013-06-26 Thread Tom Parker
On 26/06/13 00:22, Barry Vercoe wrote:
> Tom, it's not correct to say the laptops will remain in Maori.

Sorry, I should have clarified that I was referring to the keyboard only. I 
think the difference between the current olpc keyboard and a customized Maori 
one will be minor. We'll replace the æ œ ̬  ̣  ̭  characters with the macron 
vowels. I don't think this will present any problems if we make it difficult to 
reverse until a Maori keyboard and a keyboard chooser are built into the 
operating system.

I don't know how to do the windows style grave modifier on linux and for 
consistency with other Linux Maori keyboards, I think alt-gr - vowel will be a 
better starting place than the default setup.

Switching the rest of the laptop to other languages is a different matter and I 
wouldn't propose to stop that!

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel