[Libdlo] [ANNOUNCE] displaylink-mod-0.3(alpha) (was udlfb)

[jasonlife]

I have tested this new version with my Samsung LD190G, but it still doesn't
work properly.

I tested the monitor on my laptop with Ubuntu 9.04.  I can start X server on
both screens (internal and samsung), but samsung monitor doesn't display
anything.  I can start "xterm" on both screens using ssh access tough,
like;

"xterm -display :0.0; xterm -display :0.1"  works.

If I start my laptop with Samsung monitor plugged, then nothing shows up on
any monitors in the end.  I started X server manually after I booted up the
laptop without Samsung monitor in recovery mode.

JAK

On Wed, Jul 8, 2009 at 1:35 AM, Roberto De Ioris <roberto at unbit.it> wrote:

> Hi all,
>
> on http://projects.unbit.it/downloads/displaylink-mod-0.3.tar.gz
>
> you can download the first 'alpha' release of a totally refactored
> kernel module.
>
> This new branch includes dynamic mode settings and a prototype of a
> rock-solid framebuffer that can survives detach (and re-attach ?) of
> devices.
>
> The code has been split in different files, and some new ioctls has been
> added to support a new xorg driver (still working on it) with full
> xrandr support, included the merging of (virtually unlimited)
> displaylink devices in a unique (big) framebuffer.
>
> I will not work anymore on the udlfb driver, but i will release a
> 'stable' release of displaylink-mod as soon as i have solved all of the
> hotplug stuff.
>
> *** Some notes for tester ***
>
> - the driver allocates all the framebuffer space (1900*1200*2) so its
> unsuitable for embedded devices, i will add a module param to limit the
> amount of allocated memory (and so the resolution)
>
> - you can change resolution of fbcon using the fbset utility, the module
> setups the resolution always on the best supported mode.
>
> - when you detach a devices that is still in use, the framebuffer is not
> deallocated until the last process using it is killed. (but there is
> probably a race condition that lock the fbcon)
>
> - error handling (most of all on probing code) is horrible, so expect
> some oops in case of some allocation failure.
>
>
> As always, thanks to Unbit and Marvell for supporting my work.
>
> --
> Roberto De Ioris
> http://unbit.it
> JID: roberto at jabber.unbit.it
>
> _______________________________________________
> Libdlo mailing list
> Libdlo at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libdlo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/libdlo/attachments/20090708/1263fba9/attachment.html