Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - phenigma

Pages: 1 ... 59 60 [61] 62 63 ... 106
901
Installation issues / Re: Multiple sound cards, selected at random?
« on: February 10, 2013, 10:11:28 pm »
Is Multi-Channel audio and Multi-Soundcard the same option?
Are multiple sound cards required for running multiple Slim Device players? (linuxmce + squeeze[anything] pulls search hits for softsqueeze, squeezeslave, logitech media server, slim-devices, and about 30 others I cant recall offhand.  I just want to use use Slim Device Squeezebox Players/emulators).

This may be of assistance with your initial issue of the sound card devices being detected in random orders on boot:
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Set_the_default_sound_card

A multi-channel analog out (like on most Motherboards these days) can be split into seperate stereo outputs and used for seperate squeezeslaves.  This split is configured in asound.conf, here is an example:
http://forums.debian.net/viewtopic.php?p=422129

hth.

J.

902
Thanks posde!  I wasn't sure if it was in the repo yet or not.

J.

903
Users / Re: New Asterisk feature or is it my Gigaset?
« on: February 06, 2013, 11:35:05 pm »
Thanks posde!  I should have checked that first.

J.

904
Users / Re: New Asterisk feature or is it my Gigaset?
« on: February 06, 2013, 10:39:16 pm »
Okay, this sounds probably stupid on my part, but you're used to that from me, I suppose.
I'm using a Gigaset 610 IP together with LMCE and thats all working nicely so far. Today, when I came home I noticed a missed phonecall. Upon checking it on my Gigaset, I was astounded to see the full name of the caller in the display. It was somebody I knew, but didn't have the number for, so clearly this info came from somwhere else.
Right now I'm a bit confused, where this nice feature comes from...is Asterisk now automatically doing a reverselookup or is this something my Gigaset does on its own?
I'd appreciate your input.

Hey maverick, most callerid features that I've seen pass both the name and number of the called to the device.  Usually it's a feature of the provider that you can enable/disable in your voip account.  The gigaset does not do reverse lookup and to my knowledge LMCE is not doing any reverse number lookup either. 

Second, I also have a Gigaset 610 IP and I was just going to try implementing it and a voip line with my lmce production system.  Any advice on setup/integration with lmce? 

J.

905
I really want to beat whomever did the udev rules for these devices to a fucking pulp...

-Thom

Agreed.

J.

906
Sure, here it is on the accelerometer machine (hp6710b):

Thanks jamo!  You're device does not present ID_INPUT_JOYSTICK=1.  Your device will not be erroneously detected after the next snapshot is released.

J.

907
Thanks for having a look at this. I will try to apply and test your patches on my false positives (hp6710b notebooks accelerometer) and let you know. Will be great if this is addressed.

You're welcome, it's been buggin the crap out of me too :).  Just for completeness, could you post the output of:
Code: [Select]
udevadm info --query property --name /dev/input/js0for your accelerometer device.  (Accelerometer in my laptop doesn't present at /dev/input/js?)  I know it will not mis-detect a mouse device now but I'm not sure what the accelerometer presents as.

J.

908
There are two 'fixes' to repair the issue.  The first is script based only and will fix improper initial detection.  The USB_Game_Pad (c++) fixes the same issues AFTER a game pad has been detected.  USB_Game_Pad and the detection radars are independent.  All is working great here so I'm hopeful it will be rolled in soon.  I can provide copies of the scripts which, after you delete the existing GamePad devices in webadmin, will no longer detect and add new game pad devices.  Once a joystick device is plugged in it would create the game pad device and USB_Game_Pad takes over at that point.

If your issue is solely that you have erroneous detection and want that to stop.  You can use the following scripts as replacements then reboot the core/md in question (to reload the detection radar) and delete the existing game_pad devices from webadmin.  As long as you don't plug in anything that presents as a joystick then USB_Game_Pad should not run after this.

http://pastebin.com/nLSpwphr <- Gamepad_Detect.sh
http://pastebin.com/FbW50EiH <- AVWizard_Gamepad_Detect.sh

J.

909
Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 04, 2013, 10:17:57 pm »
No log for the child.  I expect that entries from the child would make it into the UIRT's log, but I don't know.

J.

910
Fixes are in svn for erroneous detection issues. 

I also fixed an issue where the detection radar only functioning properly if a joystick was plugged in, for the first time, after bootup.  It would not function correctly on a core if the joystick was first plugged in prior to, or during, boot.  Basically the radar is starts before dcerouter which prevents the detection message from reaching the dcerouter during boot.  The radar then would not fire any additional detection messages and the joystick was never detected.

http://svn.linuxmce.org/trac.cgi/attachment/ticket/1675/

I'm not sure when these will be rolled in, everything is working well.

J.

911
Alright, after conversation with tschak on irc I understand the issue a little bit more and it will require a bit more refactoring of the detection scripts and of the USB_Game_Pad device to function the way it needs too.  I'm am first fixing the detection scripts to detect ANY joystick existing on /dev/input/js?.  Then (hopefully) figure out USB_Game_Pad so that it will ignore non-joystick devices that present at /dev/input/js?.

J.

912
awesome. patch it :)

-Thom

Working on it.  :)  Here's a Gamepad_Detect.sh and AVWizard_Gamepad_Detect.sh that are no longer detecting my mouse as a game pad.  I'll submit to svn if I can get confirmation that it works for someone else with a gamepad and for someone who has always had the issue of improper detection of non joystick devices.

http://pastebin.com/VYAVp97U <- Gamepad_Detect.sh
http://pastebin.com/nJuvWJFu <- AVWizard_Gamepad_Detect.sh

J.

913
To illustrate my previous e-mail, and as tschak pointed out earlier, devices will either have or not have ID_INPUT_JOYSTICK=1. 

Here is the udev output from the mouse in my VirtualBox Virtual Machine that is consistently detected as a joystick, notice there is no ID_INPUT_JOYSTICK=1, it has ID_INPUT_MOUSE=1 instead.  Why it is mapped to /dev/input/js0 as well as the normal mouse input I have no idea.

Code: [Select]
# udevadm info --query property --name /dev/input/js0
UDEV_LOG=3
DEVPATH=/devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/input/input4/js0
MAJOR=13
MINOR=0
DEVNAME=/dev/input/js0
SUBSYSTEM=input
ID_INPUT=1
ID_INPUT_MOUSE=1
ID_VENDOR=VirtualBox
ID_VENDOR_ENC=VirtualBox
ID_VENDOR_ID=80ee
ID_MODEL=USB_Tablet
ID_MODEL_ENC=USB\x20Tablet
ID_MODEL_ID=0021
ID_REVISION=0100
ID_SERIAL=VirtualBox_USB_Tablet
ID_TYPE=hid
ID_BUS=usb
ID_USB_INTERFACES=:030000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usbhid
ID_PATH=pci-0000:00:06.0-usb-0:1:1.0
DEVLINKS=/dev/char/13:0 /dev/input/by-id/usb-VirtualBox_USB_Tablet-mouse /dev/input/by-path/pci-0000:00:06.0-usb-0:1:1.0-mouse

J.

914
OK, so the package is installed if required, but I can't see why the GamepadCmd variable is set because I can't figure out where/if it's ever used?
...
 snag is... that "GamepadCmd" bit... what is that used for and where does it come in. Is it a necessary step I'm missing out?

The GamepadCmd environment variable is read by the actual AVWizard (a C++ program) and it's contents are executed by AVWizard to start the GamePad device.  It also takes care of removing the device when the AVWizard completes.

When AVWizard completes, the GamePad Radar (Gamead_Detect.sh) takes over detection..

It seems to me that the easiest way to implement this might be to simply alter the existing detection scripts.  Run 'udevadm info --query property --name /dev/input/js0' on each detected device and grep it for 'ID_INPUT_JOYSTICK=1', if that returns a value then activate the gamepad.  Likewise don't activate the device in the radar (or set GamepadCmd) if the grep returns nothing.  The udev rule would likely be more efficient on cpu resources.

J.

915
Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 02, 2013, 08:27:46 pm »
I know the embedded transmitter (usb uirt embedded transmitter) is a child device, sort of a dummy device as referred to by Tshak, but should it still have a log file? Only the parent has a log file in my case (the parent being the receiver, which is working).

I do get the "some devices failed to start" message when I start up my MD. How do I track down which devices? Is it possible that the embedded transmitter is the one failing? Is it supposed to start (being a dummy/child device and all)?

Hmm, try the log for the Orbiter?

J.

Pages: 1 ... 59 60 [61] 62 63 ... 106