- there are numerous visual artifacts, appearing especially in
gradients. A good example is GTK drop-down menus, like the "Applications" or "Places" menus in the panel. After reading the forums, it appears that the display is 16bpp, that may be the cause.

- the driver/GPU doesn't support composite. This may be because of the 16bpp screen.

- the device often locks up and doesn't respond to any input. At first
I thought it was an OOM issue, but it turns out it was only half full
most of the time. Then I thought perhaps the SSD is very slow, but
while it's not exactly fast, it didn't show to be excessively slow. I
don't really know what could cause this. I turned off swap just in case, and the machine still locked up frequently even with ram half full, especially when running large applications (Firefox/Chrome).

- as a related issue, the OS reports that the machine has 408MB ram,
not 512. I assumed that part of RAM was used by the GPU, but 100mb
seems excessive. Especially since the GPU isn't being used much most of the time (no composite).

I tried flashing the Ubuntu image again, but that didn't
fix anything.

This is a hardware limitation and not genuinely an "issue".
You need to actually run a Compositing Manager for Xorg to actually use the Composite extension. For our systems: open a terminal, run "gconf-editor" and browse to "apps->metacity->general" and click "compositing_manager" and you will be compositing until the cows come home.

For some reason unless you can do Compiz (i.e. composite in 3D) Ubuntu or GNOME or whatever is making the distinction doesn't care if the driver supports the extension or not. We uninstalled Compiz because it was pointless to ship something that would refuse to run.

Remember this is NOT a desktop processor, it's an ARM SoC. It doesn't have full desktop OpenGL. While OpenGLES is a good subset of desktop OpenGL, most people don't write for the embedded API (actually identical it just has a few less features which are very uncommon in use outside of console gaming) or the EGL windowing API.

Until developers work out that OpenGLES is a valid API (and it is, AMD and nVidia consider it important enough that they ship EGL and OpenGLES with their desktop drivers now) and modify the GL apps (including Compiz, which Linaro are supposedly doing) then you are going to see funny little things like that.
Okay... noted.
The GPU is being used all the time. You are wrong about compositing. In actual fact what we reserve is 32MB for the IPU (which is the thing that handles the display) and 32MB for *both* GPUs. We are looking at revising these values, but it will stay around ~64MB.

Whatever's left that is missing is just what disappears by running the kernel (code section, init leftovers, etc.)

How do you figure that it's excessive considering you can't get past it being half used?

_________________
Matt Sealey

It's a troublesome hardware limitation that I didn't know of before I got it.
I see. I had tried KWin, Compiz, E17 and xcompmgr, and neither seemed to work. Didn't think of trying metacity. I hadn't expected Compiz to run anyway, I know it uses GL.

It's frustrating to notice that after enabling composite in metacity, the artefacts caused by the screen are even more noticeable, since there are shadows.
Any idea on what might cause this, or if it can be remedied software-wise?
I see. Several tabs in Chrome drive it OOM sometimes, so an extra 50mb might help. I guess the solution is to avoid Chrome, but Firefox doesn't fare much better.

I apologise for complaining so much, but I can't really use this laptop as my main computer if it locks up apparently randomly and the screen can't be used for image editing, regardless of how much I like it otherwise.

Of course, we understand. We can either swap out the unit you have or refund your purchase. In any case, please return the unit so we can fully investigate the problem. Thank you.

R&B

_________________
http://bbrv.blogspot.com

I experience a similar problem: a lock-up with the image of the screen like if it was "shaken", this happens after an unpredictable amount of time (from a few minutes to more than one hour, it even happened once during boot time). Tried to switch wifi off, to disable swap, etc. without success. Showed it to my sysadmin at the University, he suspects a problem with the graphical card (but could not find any info logged from X).
Could it be linked to the temperature? This afternoon my smartbook didn't lock up (while temperatures are above 20 Celsius instead of around 17 when I experienced many lock-up).

The vast majority of Netbooks ship with 16-bit panels..
The lockup, I am concerned about. Is it just hanging or is it displaying any graphical corruption?

There seems to be an issue with a very small number of units where what seems to be a bad chip or something similar is causing a display effect as if things have shifted on different planes. It may be affected by temperature or just be completely random. So far the number of affected units is in the fractions of a single percentage point.. we are just replacing these.

For a lockup which we may be able to trace to software (i.e. screen locks and is "solid", system is unresponsive except to holding down the power button to turn it off), this is something different, and we will investigate it, but I have never personally seen the Smartbook lock up.

_________________
Matt Sealey

After the lockup, the screen image stays firm (until I power off), most of the time it is like if two copies of the same images were displayed with one of them shifted. Sometimes, the shifted image has only one color component (like blue component shifted).
Should I return my unit or do you expect to find a fix?

That definitely sounds like a hardware issue parisse, and if you return the unit we will replace it.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

I ordered it at Genesi Europe, where should I return it?

But normally 18bit displays have dithering working correctly somewhere in the hardware or software stack... I checked the software and there is no interface in X or fb to enable dithering in an hardware neutral way (fbdev drivers seem to pass through most commands) and from another post of yours it looks like until mx53 comes out hardware won't be able to dither, too. Just to confirm, the IPU wasn't able to dither either, right? That feature is for some weird reason missing in the list of features.

Whatever the outcome, either the fb driver in X needs to get dithering support or the driver.

There is no way to enable dithering: the problem is that the panel has a direct 16-bit LVDS interface (5/6/5 just like the display) and the IPU is connected to the MTL017 with 5/6/5 too - in this instance dithering has nothing to work with.

This is the fundamental design flaw here, it could have been connected at full 24-bit to the controller, and the controller could dither down to 16-bit to the panel, but it just wasn't implemented this way for cost reasons (the 16-bit only version of the MTL017 is cheaper, the dithering matrix is totally undocumented and it was too late to find a new controller)

As I have said in previous posts it is already resolved in MX53 designs as they contain a real LVDS bridge in the chip, therefore no choice of controller is required - the MX53 will directly output to a high resolution panel. However, we may still connect the 16-bit panel as 16-bit depending on the ability of the panel and of course, cost.. it doesn't make sense to price it out of the market so a minimal number of users can benefit from a $30 more expensive panel.

I am sorry that it is not meeting your needs, please be sure we have taken your issues into account along with the other issues for the next design and will weight them accordingly.

_________________
Matt Sealey

Except that the 2d core can work with 32bpp framebuffers (or fbset -a -depth 32bpp is pulling a leg on me). That's why I asked if the IPU can convert 32bpp down to 16bpp as it is the last step and mixes VPU and GPU output if I read the documentation correctly.

But this goes to deep for the users subforum, I will open a new thread in developers if I want to talk about it in detail.
Now that isn't really an issue the panel is fine and it really is a problem with the dithering.
I will play around a lot more and if I find something interesting put something up. Are you already done with the design? Did I miss a thread with questions about what could be done better?

It definitely can - we default the Smarttop (since it has HDMI connected to a 24-bit display bus) to 32bpp.
What it says is not exactly what it is actually doing, conversion it states is more like "we take weird pixel formats and make them the same" than "we can downconvert and dither them all". The conversion is pretty simple bitswizzling and focuses on YUV to RGB, and pixel packing. Outside of YUV to RGB there are no clever coefficients to set for dithering operations.
There is one very large, very insurmountable problem: you can't dither 16-bit to 16-bit, there is no extra colour information to replicate..

Unfortunately your best bet is to rely on software to do it, which GNOME does already; if you're using the default Ubuntu backdrop, you may notice it looks very, very smooth. Open this in a paint package which does not dither the output like the GNOME desktop does, and you will see it is banded to hell.
Believe me, if you thought of it just now, you can guarantee we thought of it 6 months ago :)

As many issues as we can keep within budget will be implemented, the panel and the touchpad being my personal bugbears..

_________________
Matt Sealey

Return it back to the Genesi Europe store, if in doubt, reply to the email about your order and they can assist you further.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

I know the display is a dumb backend, I was talking about the quality of the display as a device to display something because you talked about buying $30 more expensive ones, but the problem the thread starter had was with the dithering, not the quality of the display itself...

(And if you thought that I wanted to take the 16bit output from the IPU, then no, the only way without the technical documentation is to use the framebuffer and its shadow buffers and do some hacking. This way I lose all acceleration, but there was none to begin with under debian.)
Yes, I know, except this approach only works on 16bit with the desktop only (except I disable transparency, then I could do something to enable dithering by default everywhere, but even that gets ugly fast).
I wouldn't have guessed otherwise, I was more interested in the list itself as every user has different problems (except the touchpad, display and my pet peeve the unusable arrow keys). I was just very excited to play with this laptop. The touchpad problem can be solved in software, the keyboard seems to be an industry standard so I can probably swap it out and the output is solved in the next version. Everything is looking good for me.