On Thu, Jul 23, 2009 at 8:59 PM, Mauro Carvalho Chehab<mchehab@xxxxxxxxxxxxx> wrote: > Em Thu, 23 Jul 2009 16:29:02 +0200 > Markus Rechberger <mrechberger@xxxxxxxxx> escreveu: > >> On Thu, Jul 23, 2009 at 4:05 PM, Devin >> Heitmueller<dheitmueller@xxxxxxxxxxxxxx> wrote: >> > On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@xxxxxxxxx> wrote: >> >> There's a pretty good disclosed detection from Empia available, the >> >> linux kernel driver >> >> just doesn't support it and very likely will never support it. Instead >> >> of doing it the >> >> wrong way it's better to turn it off or explicitly ask the user if he >> >> wants to do something >> >> undefined with his device. >> >> The nvidia setup tools also provide an option to force it instead of >> >> letting the software >> >> just do whatever some developers don't know what it will cause... >> >> You don't know what will happen to the device when doing that detection. >> >> The initial device in question had to be replugged after we removed >> >> the driver from the system. >> >> You shouldn't invite people to do undefined things with their hardware >> >> so they might break them >> >> I think I will submit a few photos what physically can happen to the >> >> device with wrong settings. >> > >> > Well, if there is a known heuristic, I would be very happy to get rid >> > of the autodetection logic. I haven't looked at the Empia code in >> > months so I should probably do that. >> > >> > Since I used to design hardware for a living, I am quite familiar with >> > what can happen with incorrect GPIOs so I do not believe you need to >> > attempt to convince me with photos, which is why I am in favor of >> > removing the logic in question. We just need to figure out how to do >> > it without causing a regression in current device support. >> > >> > Interesting... I took a quick look at the code, and it seems like the >> > USB errors occur before we change any GPIOs, and more interesting it >> > appears that the em2861 itself is wedged (which I believe is the first >> > time I've seen that). The code in the log above suggests that the >> > autodetection concluded that the profile was not known, so it did not >> > arbitrarily pick some incorrect device. I am a bit surprised that >> > just reading the eeprom once and doing a scan of the i2c bus would >> > wedge the chip. >> > >> > Is there any information you can give about the board in question in >> > terms of what product it is or what components it contains? >> > >> >> it was a simple TVP5150 based device... >> >> I do not mean my old code either it's also a failure as I got more information >> for the new driver after we dropped the old project. >> As you know the new driver is entirely in Userpace and supported by all involved >> chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack. >> >> Also vendors have a very low interest in supporting those devices in Kernelspace >> as installing devices which should be sold now are not supported by >> any distributions. >> Devices which have been sold one year ago have a very low till no >> motivation anymore. >> Most people are simply not able to compile the drivers and/or prepare >> the kernel development >> environment just for installing and using a TV Card. > > PLEASE STOP WITH FUD. THIS FORUM IS FOR OPEN SOURCE DRIVER DISCUSSION. AS YOU > DECIDED TO GO TO THE DARK SIDE, PLEASE STOP POSTING HERE OR AT THE OPEN SOURCE #IRC CHANNEL. > someone has problems here? We also support available opensource players and will contribute some patches which can be used by all devices. Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
