Installing Ubuntu in Samsung Smart TV natively

[sectroyer]

It would be great to create some shell script that would do everything automatically For instance you pass it a usb with ubuntu on it and it sets up everything automatically

[bobiturboto]

@bobiturboto:

Hum, I'm not quite sure what could be the problem, could it be that the pre-built filesystem does not match your TV's processor architecture? Maybe you need a different Ubuntu build, that does match your hardware (I actually have no idea what are the specific differences between hardware in E and F series...)

~Sky

Code: Select all

Processor       : ARMv7 Processor rev 3 (v7l)
Features        : swp half fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 3

Hardware        : Samsung SDP1202 evaluation board

Unfortunately probably you are right. I've tried with ubuntu-core-14.04-core-armhf and the result is the same.

@all
Please.
Please, let's somebody else with F8000 repeat my test just to be sure that my setup is correct.

[Sky]

Yes, for the time being I'm not using an automatic script, but I have all the useful commands in a txt. Eventually an script will be ideal.

@bobiturboto

There has to be a Linux filesystem compatible with your TV model, it would be a matter of finding it.

[sectroyer]

@zoelechat:

Sure, as soon as I find some time to rewrite some parts I'll do it. However I'm trying to enable proper mouse support by tweaking the xorg.conf file (now that I can bind it), and... No dice :/. Maybe I'll have to write that /dev/mice -> XdoTool script, I'm gessing that should work ^^".

~Sky

Isn't X restart necessary to make X reread the Xorg.conf?

[sectroyer]

Okay so the TV doesn't have /dev/input/ directory but it has one in /dtv:

Code: Select all

 find /dtv/input/
/dtv/input/
/dtv/input/mice
/dtv/input/event4
/dtv/input/mouse4
/dtv/input/event3
/dtv/input/mouse3
/dtv/input/event2
/dtv/input/mouse2
/dtv/input/event1
/dtv/input/mouse1
/dtv/input/event0
/dtv/input/mouse0

There is also:

Code: Select all

/dev/mice

Which also reads raw data from mouse...

[Sky]

Indeed one has to restart for the Xorg.conf to be reread, what I did was to mount the new conf file in a start script, and restart the TV, but made no difference.
About /dev/input/mice, you're right, I created it inside Ubuntu, but in Xorg.conf I was using /dev/mice, which works as expected (I guess it's the same device as /dtv/input/mice).
So no idea why there is no proper input once Ubuntu has been loaded. The XdoTool solution might be a dirty workaround but I'll have to actually consider it xD

~Sky

[sectroyer]

I suspect by "start script" you means start.sh? Be careful with that!!! One error and you have a brick... I think we have "attack" the original /dev directory and not the chrooted one since X runs outside of chroot... Whenever we ask X to look for input devices it checks there;) Also does the X use mouse at the moment? I think it's exeDSP itself that handles the Mose device. Also I read that X should detect new connected mouse device automatically. Maybe it will detect newly connected mouse if we patch it...

[sectroyer]

BTW both mice devices look completely the same:

Code: Select all

root@tv:~ # cat /dtv/input/mice > /tmp/mouse1.bin&
root@tv:~ # cat /dev/mice > /tmp/mouse2.bin&
root@tv:~ # md5 /tmp/mouse*
/mnt/bin/sh: md5: not found
root@tv:~ # md5sum /tmp/mouse*
d41d8cd98f00b204e9800998ecf8427e  /tmp/mouse1.bin
d41d8cd98f00b204e9800998ecf8427e  /tmp/mouse2.bin
root@tv:~ # md5sum /tmp/mouse*
9ac6bd6147c7992902643894df3afca7  /tmp/mouse1.bin
9ac6bd6147c7992902643894df3afca7  /tmp/mouse2.bin
root@tv:~ # md5sum /tmp/mouse*
c911aaba72b89778bf7e5b18d5ea918a  /tmp/mouse1.bin
c911aaba72b89778bf7e5b18d5ea918a  /tmp/mouse2.bin

Connecting, moving, moving, disconnecting

[Sky]

Yeah, they should be the same, even if we create a device node inside the chroot, as long as we use the same major and minor numbers, they will be the same device, as those are used at kernel level, the fastest solution is to bind the /dev directory.

And yup, is pretty risky messing around with start.sh. And yeah, I also think it's the TV higher level software (exeDSP) the one that directly controls it (and probably graphic acceleration too), cos otherwiswe IDK why the mouse only works there and ignores any possible linux desktop environment (the same happens when using LXDE).

I also read that X should detect the mouse automatically, but it doesn't happen: tools like xinput or udevadm do not register any pointer device once the mouse has been connected, even though lsusb do list all its properties (down to the mouse manufacture and model). And this is all with a perfectly working mice device inside the chroot.

At first I thought this may have something to do with both "mouse" and "kbd" drivers not being present on the XServer (as the xlog.txt files says), but then I read this is completely unrelated. Weird...

...

[sectroyer]

Yeah, they should be the same, even if we create a device node inside the chroot, as long as we use the same major and minor numbers, they will be the same device, as those are used at kernel level, the fastest solution is to bind the /dev directory.

And yup, is pretty risky messing around with start.sh. And yeah, I also think it's the TV higher level software (exeDSP) the one that directly controls it (and probably graphic acceleration too), cos otherwiswe IDK why the mouse only works there and ignores any possible linux desktop environment (the same happens when using LXDE).

I also read that X should detect the mouse automatically, but it doesn't happen: tools like xinput or udevadm do not register any pointer device once the mouse has been connected, even though lsusb do list all its properties (down to the mouse manufacture and model). And this is all with a perfectly working mice device inside the chroot.

At first I thought this may have something to do with both "mouse" and "kbd" drivers not being present on the XServer (as the xlog.txt files says), but then I read this is completely unrelated. Weird...

...

I think we are both going in the same direction No point discussing it here (to many speculations, to little facts...).