LinuxMCE - User contributions [en]

Windows MCE Remote

2015-06-21T14:57:56Z

Joerod:

[[Category: Hardware]]
{{versioninfo}}
[[Category:Input]]
[[Category:Infrared]]

USB Remote intended for Media Center PCs
*Vendors Website: http://www.microsoft.com/hardware/mouseandkeyboard/productdetails.aspx?pid=065
*Supported by LinuxMCE when used with one of the supported [[:Category:Infrared |Infrared Receivers]].
== Media Center Remotes ==

{| border=1 cellspacing=0 cellpadding=2
|
| [[Image:MCEremote.jpg]]
| [[Image:MCE-Remote-2.jpg | Media Centre Remote 2]]
| [[Image:MCE-Remote-2-alt.jpg | Media Centre Remote 2 ALT]]
| [[Image:Mce-hauppauge.jpg | MCE Remote Hauppauge version]]
| [[Image:MCE-Remote-2-v1069.jpg | MCE Remote Hauppauge Windows Vista version]]
|-
| Version
| <center>1</center>
| <center>2</center>
| <center>2</center>
| <center>2</center>
| <center>2</center>
|-
| Model
| <center></center>
| <center>1039</center>
| <center>1039</center>
| <center>Hauppauge PVR- kit</center>
| <center>1069</center>
|-
| Features
| <center>Backlight</center>
| <center>Backlight</center>
| <center>Backlight</center>
| <center>"My" Buttons</center>
| <center>Uses mceusb2 lircd.conf</center>
|}

===Description===
There are two main versions of the MCE remote, typically referred to as the 'older' (Version 1) and 'newer' (Version 2) models. Both of these are now supported in the latest lirc, currently 0.8.1.

The newer remote comes in various alternatives, including different shapes and features. The new model is manufactured by Philips and half a dozen other manufacturers and is available by (among many other ways) purchase on it's own, shipped with MCE 2005 and contained in Hauppauge TV card MCE-Kits.

===Support===

====Version 2 ====
* [[Windows MCE Receiver|IR Receiver]] is supported
**The easiest method of installation is via the [[LinuxMCE Admin Website]]
***Click on [[Media Directors]]
***Scroll to the bottom of the list of configurable items for Infrared remote controls you will use and select "Windows XP MC Remote" from the drop down list which matches the [[:Category:Infrared |Infrared Receivers]] you have installed, this will automatically update the lircd.conf file.
***Reload the Router and you should be good to go.
* IR Transmitter is supported with driver module lirc_mceusb2 version >= 0.24 (lirc-0.8.2).
**Although not currently Officially supported in LinuxMCE, you can follow the instructions in the following post to get it working:
***http://wiki.linuxmce.org/index.php/Windows_MCE_Receiver
* Version 1069 (black remote) comes with a new SMK IR receiver which requires new lirc_mceusb2 (Version 1.30)
** The new SMK IR receiver requires a newer version of LIRC than currently ships with LinuxMCE 704.
** Refer to the following forum posts for more information and possible fix:
*** http://forum.linuxmce.org/index.php?topic=2678.0
*** http://forum.linuxmce.org/index.php?topic=2517.0

==== Version 1 ====
* IR Receiver is supported
* IR Transmitter is not supported

====Hauppauge PVR-150 Remote====
The [[Hauppauge WinTV-PVR-150 MCE]] comes with an MCE compatible remote, as of LinuxMCE version 0710, it does not work out-of-the-box. See [[Alx9r's PVR-150 Remote Setup]] for an example of how to set this remote up.

====Philips SRM 5100 MCE Remote====
[[Philips_SRM_5100_MCE_Remote]]

==Troubleshooting==
# Currently the lircd.conf file is located in the /etc/lirc/ directory which is not where the scripts are trying to update the lircd.conf file. You need to go to the /etc/lirc directory and vi hardware.conf and add /ect/lircd.conf as the location of the lircd.conf file. Then cd into /etc directory and vi lircd.conf and save a blank file, now the scripts will be able to update the lircd.conf file with the appropriate remote control data.
# I have newer version of Windows MCE Remote, and I can not get it to work. Please refer to the following posts for possible solutions: http://forum.linuxmce.org/index.php?topic=2678.0 and http://forum.linuxmce.org/index.php?topic=2517.0
# I had a problem where all clicks would register twice and found this to be very helpful: http://forum.kodi.tv/showthread.php?tid=89190 Basically [adding echo none +lirc > /sys/class/rc/rc0/protocols] to rc.local

==See Also==
* [[Windows MCE Receiver]]
* http://www.mythtv.org/wiki/index.php/MCE_Remote

KDE TINY FONT

2014-02-08T17:52:17Z

Joerod: Created page with "http://ubuntuforums.org/showthread.php?t=1691224 Rant: I think the most common understanding of DPI/resolution/font-size/etc is summed up by the phrase "screen real-estate:"..."

http://ubuntuforums.org/showthread.php?t=1691224

Rant:

I think the most common understanding of DPI/resolution/font-size/etc is summed up by the phrase "screen real-estate:"

- I buy an expensive screen with a high resolution so
- I can sit close to it
- and fit lots of tiny text on it.

Most screens have a physical DPI around 100 or so, the OS (originally Windows) can safely assume a fixed DPI, and most people sit close to a monitor. Higher resolution = bigger screen = bigger field-of view.

Monitor makers like it because it gives them something to charge for.

Print artists want the ability to make the image-on-screen match the physical size of the image-in-print. Thus, monitors have the ability to tell the OS what they're physical size is and everything works for the graphic designer. I understand this is OS X's behavior.

Finally, there's the approach inherited from film projection / TV / home cinema: the larger the screen, the further back and larger the sweet spot becomes. The higher the resolution, the finer and sharper--not smaller--the image. Since the viewer sits back, a 24" screen doesn't cover any less or more viewing area than a 36" screen. Physical size doesn't matter. But, an image on a 1200-line screen should be twice as many pixels high as on a 600-line screen.

For this user, 1 point is not 1/72 of an inch. It's some fraction of the screen height. Exactly which fraction should be adjustable and determines how big or small everything is: text, applications, icons.

If an OS can satisfy this last user, it can satisfy the first. He can just crank the scale down so everything's as small and blurry as he can stand. Or, if your big TV/monitor is halfway across the room, crank things up and enjoy big, crisp, easy to read text.

There's a magic point here screen size matches print size and the OS should make it button-push easy to set things up that way if the user wants. Everyone would be happy and peace would reign.

But, KDE doesn't make things easy; you either get (bad) OS X aping or a more authentic Windows aping with forced DPI.

---

Technical:

So, how do you set DPI in KDE? Well, if you want either 96 DPI or 120 DPI, you're in luck. System Settings -> Application Appearance -> Fonts -> Force Fonts DPI

But, I want my screen to hold as much text as an 8-inch tall piece of paper: vertical resolution, 1200 dots / 8 inches = 150 DPI. No luck there.

I've tried setting ScreenSize to 200mm in xorg.conf. xdpyinfo still gives the physical screen size. Setting that with xrandr --fbmm at least changes what xdpyinfo returns, but KDE ignores that.

still looking...

---

In /etc/kde4/kdm/kdmrc
ServerArgsLocal line
add -dpi XX to the end.

Changes text size and xdpyinfo, but doesn't rescale icons nor do all applications obey. In particular, Google Chrome is hard-coded to 96 DPI.

Bluetooth Input

2014-01-05T17:57:12Z

Joerod: Created page with "Category: Bluetooth This is not yet complete, but this link should be enough for one to get it working... [http://forum.xbmc.org/showthread.php?tid=103503]"

[[Category: Bluetooth]]

This is not yet complete, but this link should be enough for one to get it working...
[http://forum.xbmc.org/showthread.php?tid=103503]

DVD

2013-12-30T02:20:09Z

Joerod:

This page outlines information about DVD playing with LinuxMCE.

As the [[Xine|Xine Player]] is used to play DVD, most of the settings can be changed in the $root/etc/pluto/xine.conf configuration directory. $root points either to the root directory of the Core/Hybrid, ie. the file is /etc/pluto/xine.conf, or one of the diskless orbiters. The diskless orbiters file is /usr/pluto/diskless/$orbiter-id/etc/pluto/xine.conf.

== DVD Language ==
To change the default DVD language from the current english, locate the line
#input.dvd_language:en

remove the hash and change it to the preferred language. For example, changing it to german, the line looks like this:
input.dvd_language:de

== Audio Output via SP/DIF ==
If you have problems sending sound out thru your digital outs (SP/DIF coax or optical) have a look at the [[Sound_Cards#xine.conf|Sound Card]] page.

== libdvdcss2 ==
In 1004 (as of 12/29/2013) I had to do the following to get it work:
echo "deb http://download.videolan.org/pub/debian/stable/ / " >> /etc/apt/sources.list
apt-get update
apt-get install libdvdcss2

[[category: programmer's Guide]]

Unrecognized NIC

2012-10-14T23:40:37Z

Joerod:

{{versioninfo}}
[[Category: Networking|NIC]]
[[Category:Network Adapters|*]]
[[Category: Troubleshooting]]

'''Note''' If you have a r8168 NIC, see the [[r8168]] page first.

Every now and then, people come along with NICs that are not directly supported by LinuxMCE. Typically when this happens you will see a 'Kernel Panic' during the initial PXE boot process. The following information should help to get even those NICs to work. As an example, the ASUS P5K is used, which is using the Attansic L1 NIC. You may have another chipset used in your NIC which will mean that you need to find out what the chipset is and importantly what kernel module is used to add support for it. Googling the chipset name and the words 'kernel module' will normally throw up some links to help you get the module name. Once you have that information you are ready to follow the simple steps outlined below;
== Modify modules on core ==
To get a NIC to work, you have to modify a file;
sudo <editor-of-choice> /etc/initramfs-tools-interactor/modules
and add a single line for your NICs kernel module. In the above case the name of the module is
atl1
Or for the Marvell Yukon 88E8055 chip for example add;
sky2
Or for a foxconn nt330i / Aleutia H1 you'll need to download the linux drivers from Atheros http://partner.atheros.com/Drivers.aspx (or follow instructions and download drivers from http://joefleming.net/2010/05/26/atheros-ar8131-and-linux/ if that link is dead) and install them, then place the module in the modules file
atl1e

After adding the above line (and saving the change of course ;-) ), you have to recreate the initial ramdisk. For 0704 do;
/usr/pluto/bin/Diskless_BuildDefaultImage.sh
or maybe
mkinitramfs -d /etc/initramfs-tools-interactor/ -o /tftpboot/default/initrd
is enough.

This will create a new initial ramdisk for the first boot of new MDs containing the atl1 module (or in your case for whichever module you have added). Now, the first boot of the diskless MD will succeed and a new diskless media director will be created.

== Modify the media director initial ramdisk ==

Note: If your MD is 64 bit capable, but your core is running 32 bit mode LMCE, when the initial MD diskless image is built, it will automatically build a 64 bit image. A 64 bit MD image and 32 bit core is incompatible with running the "chroot" command below. If this your situation, you will need to go to the Wizard->Devices->Media Directors in web admin, before continuing, and edit the Architecture field in the applicable Media Director to say i386 instead of AMD64, hit Update and then Rebuild Image. This will delete the 64 bit image and rebuild the MD's image as 32 bit. This takes a good few minutes to complete

Note: If you had to follow the R8168 NIC driver article before this article (or had to build/make any other NIC driver before coming here to assign it to your MD), note that the diskless images are created from a compressed archive, not from your core's files. Thus any changes you made, like adding a new <nicdriver>.ko to your /lib/modules/2.6.22-14-generic/kernel/drivers/net will not be present in your new MD image. So you will need to copy these files/changes from your live core image to your new MD image in the same locations, eg...

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko /usr/pluto/diskless/''<MD#>''/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko and

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko /usr/pluto/diskless/''<MD#>''/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko

To boot this diskless MD later on, the configuration for this new device has to be modified to include the above line as well. Look in the directory structure under /usr/pluto/diskless. Each media director has a directory named with the ID of the director in here. Go into the /usr/pluto/diskless/<mediadirector-id>/etc and edit the file modules to also contain
atl1

Also, go into '''/usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools''' and put the line into a file called modules. After this, chroot into the directory of the media directory, and re-create the initial ramdisk.

To create a new initial ram disk the command is
cd /usr/pluto/diskless/
chroot <mediadirector-id>
depmod
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit

Now reboot your media director. Everything should come up, the way it is meant to.

== Troubleshooting ==

First, you need to understand what initramfs and vmlinuz are and how they are used for network booting. Vmlinuz is the first piece of code loaded (via TFTP) on PXE boot, and its entire job is to create a RAM disk, TFTP down the initramfs file, decompress it into the RAM disk, then hand control over to that code to continue. Initramfs contains a small Linux micro kernel and basic hardware drivers necessary to start networking, and mount a remote NFS share locally as the system "disk", then hand control over to that full kernel to start running normally.

The full kernel on 0810 (and probably 0710) will likely have the correct network driver for your NIC, however that is no use if the initramfs micro kernel doesn't have the driver, as it will not be able to start networking and mount the NFS share to get to the full kernel... catch 22! It would seem (I am deducing, I don't know for sure) that the NIC "driver" in vmlinuz is so basic that it will pretty much work on any NIC, so that doesn't need to be updated, and obviously the NIC "driver" used by the PXE firmware is able to drive your NIC because it came with the computer!

So the issue is usually initramfs. But you need to understand that there are 2 different initramfs's involved... the first is the "default" one used for _new_ MDs - ie MDs that have never been seen before my LinuxMCE. The instructions for that are at the top of that article. These are the easy ones to follow. The second is for after LinuxMCE has run the initial discovery on _first_ boot of your MD and assigned a device number, rebooted the MD, etc. The instructions for this one is the second part of that article and can be more difficult to follow what is going on because of the chroot bits...

Note that the first one is here /tftp/default/initrd and the second one is here /usr/pluto/diskless/##/boot/initrd... (which is then symlinked into /tftp/## ie different from the "default" location)

It is highly likely that you have successfully modified the default initramfs, so the first part of setting up an MD has gone through, and you will see it as a device in the device tree of web admin. But haven't successfully modified the second initramfs, which is used for all subsequent reboots.

The error message you are getting means that the driver module for your NIC is not loading and so the eth0 interface name doesn't get set up... ie no networking, and without that, you cannot mount the system "disk" over the network, so the kernel panics, as it cannot continue.

Note that the first uses /etc/initramfs-tools-interactor/modules the second /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules

You must edit BOTH /usr/pluto/diskless/<mediadirector-id>/etc/modules AND /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules before you chroot into the MD's files. And you must depmod before recreating the initramfs, as this is what reads those config files and tells the initramfs to load that module on start up. It can also be relevant if you modprobed the module into the kernel on the core before even creating the MD image.

One thing is certain though, once you make one stuff up, you can go back and try to fix it up but more often than not you end up in knots! It is usually better to go right back to the beginning and completely delete the MD from the device tree (and allow it to delete all the files - that's why deleting an MD is so slow) and starting again, being concious that the new MD will have a new device number, and that often it will detect it as AMD64 rather than i386, and if your core is i386 (which it should be) the chroot won't work...

BIOS boot firmware -> PXE boot firmware -> vmlinuz RAM disk bootstrap software -> initramfs Linux micro kernel boot software -> Linux full kernel

--colinjones

== Caveat ==
Whenever you click Regenerate this media director, you have to redo the step for the initial ramdisk of the media director.
The above steps do not work, if the media director and the core utilize two different CPU architectures,ie. one is using AMD64 the other i386 (chroot won't work). Note - AMD64 does not necessarily imply an AMD CPU, it just means the CPU is in 64 bit mode. An Intel CPU can just as easily be AMD64, and vice versa for i386, it can be an AMD CPU, just in 32 bit mode. i386=32bit mode; AMD64=64bit mode, it says nothing about the CPU manufacturer.

Unrecognized NIC

2012-10-14T16:26:53Z

Joerod:

{{versioninfo}}
[[Category: Networking|NIC]]
[[Category:Network Adapters|*]]
[[Category: Troubleshooting]]

'''Note''' If you have a r8168 NIC, see the [[r8168]] page first.

Every now and then, people come along with NICs that are not directly supported by LinuxMCE. Typically when this happens you will see a 'Kernel Panic' during the initial PXE boot process. The following information should help to get even those NICs to work. As an example, the ASUS P5K is used, which is using the Attansic L1 NIC. You may have another chipset used in your NIC which will mean that you need to find out what the chipset is and importantly what kernel module is used to add support for it. Googling the chipset name and the words 'kernel module' will normally throw up some links to help you get the module name. Once you have that information you are ready to follow the simple steps outlined below;
== Modify modules on core ==
To get a NIC to work, you have to modify a file;
sudo <editor-of-choice> /etc/initramfs-tools-interactor/modules
and add a single line for your NICs kernel module. In the above case the name of the module is
atl1
Or for the Marvell Yukon 88E8055 chip for example add;
sky2
Or for a foxconn nt330i / Aleutia H1 you'll need to download the linux drivers from Atheros http://partner.atheros.com/Drivers.aspx (or follow instructions and download drivers from http://joefleming.net/2010/05/26/atheros-ar8131-and-linux/ if that link is dead) and install them, then place the module in the modules file
atl1e

After adding the above line (and saving the change of course ;-) ), you have to recreate the initial ramdisk. For 0704 do;
/usr/pluto/bin/Diskless_BuildDefaultImage.sh
or maybe
mkinitramfs -d /etc/initramfs-tools-interactor/ -o /tftpboot/default/initrd
is enough.

This will create a new initial ramdisk for the first boot of new MDs containing the atl1 module (or in your case for whichever module you have added). Now, the first boot of the diskless MD will succeed and a new diskless media director will be created.

== Modify the media director initial ramdisk ==

Note: If your MD is 64 bit capable, but your core is running 32 bit mode LMCE, when the initial MD diskless image is built, it will automatically build a 64 bit image. A 64 bit MD image and 32 bit core is incompatible with running the "chroot" command below. If this your situation, you will need to go to the Wizard->Devices->Media Directors in web admin, before continuing, and edit the Architecture field in the applicable Media Director to say i386 instead of AMD64, hit Update and then Rebuild Image. This will delete the 64 bit image and rebuild the MD's image as 32 bit. This takes a good few minutes to complete

Note: If you had to follow the R8168 NIC driver article before this article (or had to build/make any other NIC driver before coming here to assign it to your MD), note that the diskless images are created from a compressed archive, not from your core's files. Thus any changes you made, like adding a new <nicdriver>.ko to your /lib/modules/2.6.22-14-generic/kernel/drivers/net will not be present in your new MD image. So you will need to copy these files/changes from your live core image to your new MD image in the same locations, eg...

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko /usr/pluto/diskless/''<MD#>''/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8168.ko and

sudo cp /lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko /usr/pluto/diskless/''<MD#>''/lib/modules/2.6.22-14-generic/kernel/drivers/net/r8169.ko

To boot this diskless MD later on, the configuration for this new device has to be modified to include the above line as well. Look in the directory structure under /usr/pluto/diskless. Each media director has a directory named with the ID of the director in here. Go into the /usr/pluto/diskless/<mediadirector-id>/etc and edit the file modules to also contain
atl1

Also, go into '''/usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools''' and put the line into a file called modules. After this, chroot into the directory of the media directory, and re-create the initial ramdisk.

To create a new initial ram disk the command is
cd /usr/pluto/diskless/
chroot <mediadirector-id>
depmod
cd /boot
mkinitramfs -o initrd.img-`uname -r` `uname -r`
exit

Now reboot your media director. Everything should come up, the way it is meant to.

== Troubleshooting ==

First, you need to understand what initramfs and vmlinuz are and how they are used for network booting. Vmlinuz is the first piece of code loaded (via TFTP) on PXE boot, and its entire job is to create a RAM disk, TFTP down the initramfs file, decompress it into the RAM disk, then hand control over to that code to continue. Initramfs contains a small Linux micro kernel and basic hardware drivers necessary to start networking, and mount a remote NFS share locally as the system "disk", then hand control over to that full kernel to start running normally.

The full kernel on 0810 (and probably 0710) will likely have the correct network driver for your NIC, however that is no use if the initramfs micro kernel doesn't have the driver, as it will not be able to start networking and mount the NFS share to get to the full kernel... catch 22! It would seem (I am deducing, I don't know for sure) that the NIC "driver" in vmlinuz is so basic that it will pretty much work on any NIC, so that doesn't need to be updated, and obviously the NIC "driver" used by the PXE firmware is able to drive your NIC because it came with the computer!

So the issue is usually initramfs. But you need to understand that there are 2 different initramfs's involved... the first is the "default" one used for _new_ MDs - ie MDs that have never been seen before my LinuxMCE. The instructions for that are at the top of that article. These are the easy ones to follow. The second is for after LinuxMCE has run the initial discovery on _first_ boot of your MD and assigned a device number, rebooted the MD, etc. The instructions for this one is the second part of that article and can be more difficult to follow what is going on because of the chroot bits...

Note that the first one is here /tftp/default/initrd and the second one is here /usr/pluto/diskless/##/boot/initrd... (which is then symlinked into /tftp/## ie different from the "default" location)

It is highly likely that you have successfully modified the default initramfs, so the first part of setting up an MD has gone through, and you will see it as a device in the device tree of web admin. But haven't successfully modified the second initramfs, which is used for all subsequent reboots.

The error message you are getting means that the driver module for your NIC is not loading and so the eth0 interface name doesn't get set up... ie no networking, and without that, you cannot mount the system "disk" over the network, so the kernel panics, as it cannot continue.

Note that the first uses /etc/initramfs-tools-interactor/modules the second /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules

You must edit BOTH /usr/pluto/diskless/<mediadirector-id>/etc/modules AND /usr/pluto/diskless/<mediadirector-id>/etc/initramfs-tools/modules before you chroot into the MD's files. And you must depmod before recreating the initramfs, as this is what reads those config files and tells the initramfs to load that module on start up. It can also be relevant if you modprobed the module into the kernel on the core before even creating the MD image.

One thing is certain though, once you make one stuff up, you can go back and try to fix it up but more often than not you end up in knots! It is usually better to go right back to the beginning and completely delete the MD from the device tree (and allow it to delete all the files - that's why deleting an MD is so slow) and starting again, being concious that the new MD will have a new device number, and that often it will detect it as AMD64 rather than i386, and if your core is i386 (which it should be) the chroot won't work...

--colinjones

== Caveat ==
Whenever you click Regenerate this media director, you have to redo the step for the initial ramdisk of the media director.
The above steps do not work, if the media director and the core utilize two different CPU architectures,ie. one is using AMD64 the other i386 (chroot won't work). Note - AMD64 does not necessarily imply an AMD CPU, it just means the CPU is in 64 bit mode. An Intel CPU can just as easily be AMD64, and vice versa for i386, it can be an AMD CPU, just in 32 bit mode. i386=32bit mode; AMD64=64bit mode, it says nothing about the CPU manufacturer.

File:Lenovoq150-3.jpg

2011-09-11T13:06:00Z

Joerod:

File:Lenovoq150-2.jpg

2011-09-11T13:05:30Z

Joerod:

File:Lenovoq150-1.jpg

2011-09-11T13:04:29Z

Joerod: uploaded a new version of "File:Lenovoq150-1.jpg"

File:Lenovoq150-1.jpg

2011-09-11T12:58:50Z

Joerod:

File:Lenovoq150-mounted.jpg

2011-09-11T12:56:45Z

Joerod: Monitor mounted Lenovo IdeaCentre Q150

Monitor mounted Lenovo IdeaCentre Q150