https://www.thinkwiki.org/w/api.php?action=feedcontributions&user=145.253.208.115&feedformat=atomThinkWiki - User contributions [en]2024-03-28T17:15:39ZUser contributionsMediaWiki 1.31.12https://www.thinkwiki.org/w/index.php?title=Talk:Problem_with_DVI_throughput&diff=8343Talk:Problem with DVI throughput2005-06-20T11:59:33Z<p>145.253.208.115: /* No problems here */</p>
<hr />
<div>Here's some information I found:<br />
<br />
Most DVI devices today use single-link DVI which supports a maximum bandwidth of 165 MHz [http://www.ddwg.org/dvi.html]. I suppose that ThinkPads provide a single-link DVI signal. <br />
<br />
To calculate the bandwidth of your signal, in theory you just need to multiply the resolution with the vertical frequency. For example: 1600x1200 @ 85 Hz => 1600*1200*85 Hz = 163 MHz. This looks good, but it is outside the specs - because you need to take into account some extra time. CRTs need a so-called ''blanking time'' between the data for two display lines. This time is needed for something similar to a carriage return on a typewriter: The electron beam needs to be returned to the start of the next line. Additionally, some extra time is needed to transmit information about the border area around the real picture. About 25% of the bandwidth is used for these additional data. [http://graphics.tomshardware.com/graphic/20041129/tft_connection-04.html]<br />
<br />
This means, that there is no specific ThinkPad problem with the throughput - you are just trying to transfer video data at a rate that is outside the specs of DVI. Maybe the DVI transmitter inside the ThinkPad even works at this data rate. But the DVI receiver inside the monitor might be "overclocked".<br />
<br />
TFTs don't really need extra time. So there is a chance of writing a display driver with a reduced blanking time. This might explain, why some people were successful with other drivers. <br />
<br />
The effective maximum resolution for single link DVI should be around 1600x1200 @ 65 Hz, or @ 60 Hz to be on the sure side. Has anyone solved his problems by lowering the vertical frequency?<br />
<br />
--[[User:137.226.40.2|137.226.40.2]] 14:23, 1 Mar 2005 (CET)<br />
<br />
== No problem on T41p ==<br />
<br />
I have a T41p with 1400x1040 LCD and a Samsung SyncMaster 213T connected through the Port Replicator II with DVI<br><br />
After some windows registry hacks I can run the Samsung in 1600x1200 in single, clone display and extend display mode.<br><br />
Linux requires no such hacks and will happily run at 1600x1200<br />
<br />
The picture through DVI is perfect with either desktop applications or running DVD video.<br />
<br />
----<br />
This is good news.<br />
Do you run Linux in DualHead, MergedFB or CloneMode?<br />
In Windows you have a clear video overlay all the time (like after every boot)?<br />
Which drivers are you using in Linux and Windows, please list the with version numbers.<br />
<br />
[[User:217.230.177.126|217.230.177.126]] 01:31, 10 Mar 2005 (CET)<br />
----<br />
<br />
==Question about DVI/LCD switching on T4x / Radeon M9 / Linux==<br />
Has anyone been able to successfully switch back and forth between the LCD output and the Port Replicator II DVI output on Linux? How do you do it? My problem is described below:<br />
<br />
[[http://forums.gentoo.org/viewtopic-t-320973-highlight-.html]]<br />
<br />
== No problems here ==<br />
<br />
I installed the new catalyst drivers 5.6 using Patje's Mobility Moddingand it works for all resolutions. My laptop runs at 1400x1060 and my dvi screen at 1920x1200.<br />
No problems that I can tell. The omega drivers (based on older catalyst drivers) blue screened my windows xp on boot.<br />
----<br />
Thanks for the info, it is a while since i tested with Catalyst and back then it didn't allow 1400x1050.</div>145.253.208.115https://www.thinkwiki.org/w/index.php?title=Talk:How_to_configure_acpid&diff=16711Talk:How to configure acpid2005-06-20T11:55:40Z<p>145.253.208.115: </p>
<hr />
<div><i>This content was merged from my original T30 specific page [[T30_ACPI_Sleeping]] that is now being redirected here. IMO this page is a mistake because the solution is specific to machines with radeon video. It would be better if someone could resurrect the origial page. Also the below script is a little sketchy.</i><br />
----<br />
As i wrote you before, the information on this page is not only T30 specific and we don't want to end up with hundreds of pages covering the same topic just designating a different machine in the name.<br />
<br />
I.e. would you like to have another page called A31p_ACPI_Sleeping? And another one X31_ACPI_Sleeping? All being the same except for the mentioned model? The instructions for these models would be precisely the same and it would only mean redundant maintenance.<br />
<br />
The overall topic of your original page is covered by the following pages:<br />
*[[How to make ACPI work]]<br />
*[[How to configure acpid]]<br />
*[[Problem with LCD backlight remaining on during ACPI sleep]]<br />
<br />
Furthermore, those pages are directly accessible from the [[:Category:T30|T30]] model page and they link to one another as well.<br />
<br />
Your only argument for having it on a separate page is that T30 users wanting to use ACPI sleep can find it more easily. I think that a user can find all the needed information pretty easily if he follows a logical path like looking on the T30 model page, and the ACPI-HOWTO page. First you want to make ACPI work in general. Then if you think you managed that but still have a problem, you look for further information, i.e. have a look into the problems pages. In this case you even don't need to since the according problem page is linked directly from the ACPI-Howto page.<br />
<br />
What if a A31p user comes to ThinkWiki with the same problem? Will he find the information when it's on a page labelled "T30_ACPI_Sleeping"? I guess not. So what do we do? Make a second page and redirect that to this page? Why then is it bad to redirect "T30_ACPI_Sleeping" to a page where all the relevant information can be accessed from? If you think this page is the wrong target, we can change it to point to the LCD backlight problem page.<br />
<br />
Furthermore, this page is not specific to notebooks featuring radeons. The general information in the beginning is acpid-specific and else generic. The example event entry is acpi-sleep and lid specific and else generic. The actual example script features 5 lines that are radeon (or T30, A30, A31p, X30 and X31) specific, as is also stated in a comment below the script.<br />
<br />
Specific for notebooks with radeons is the [[Problem with LCD backlight remaining on during ACPI sleep]] page. It is in fact even more specific, since it covers the exact problem that doesn't affect all radeon based ThinkPads.<br />
<br />
Your original page covered three different topics in one page, making it specific for exactly what your page title designated: T30s, ACPI and sleep mode. But all three of those topics are distinct topics in themselves and are not specific to your what your page title designates.<br />
<br />
If you find more intuitive page names than i did feel free to propose them, but i really don't see the point in having a separate page to maintain for each specific question a user might come up with.<br />
<br />
Wyrfel<br />
----</div>145.253.208.115https://www.thinkwiki.org/w/index.php?title=How_to_configure_acpid&diff=6790How to configure acpid2005-06-20T11:17:33Z<p>145.253.208.115: </p>
<hr />
<div>Basically, acpid just executes scripts residing in <tt>/etc/acpi/actions</tt>. Which script to launch at which event is configured in several files in <tt>/etc/acpi/events</tt>. {{cmd|man acpid}} holds detailed information on how to configure acpid.<br />
<br />
The [[ibm-acpi]] package includes example scripts in the <tt>config</tt> folder inside the tarball. They are a good starting point to adjust them to your needs. You also might want to have a look at the [[Configs#ACPI | ACPI section of the Configs page]] or the [[:Category:Scripts|Scripts]] repository. And you can find information about the event strings [[ibm-acpi]] generates for certain keys at the [[How to get special keys to work#ibm-acpi_events | Special Keys HOWTO]].<br />
<br />
==Example: go to sleep on lid close==<br />
<br />
To make the ThinkPad go to sleep when you close the lid, you need to add<br />
an event handler for the lid event and an action script that takes care<br />
of going to sleep and resuming.<br />
<br />
The event script needs to be created within <tt>/etc/acpi/events</tt> and can have any name you like.<br />
In this case we call it lid because it will trigger the lid event. Do {{cmdroot|vi /etc/acpi/events/lid}} and make it look like this:<br />
event=button/lid<br />
action=/etc/acpi/actions/sleep.sh %e<br />
<br />
The "event" line is a regular expression specifying the events we're<br />
interested in. You can determine what the event strings are from looking at<br />
<tt>/var/log/acpid</tt> after trying to suspend, close the lid, etc. .<br />
You can find information about the event strings [[ibm-acpi]] generates for certain keys at the [[How to get special keys to work#ibm-acpi_events | Special Keys HOWTO]].<br />
<br />
The "action" line is the command to be executed when these events are<br />
dispatched. In this example we call the <tt>sleep.sh</tt> script residing in <tt>/etc/acpi/actions</tt> and pass the event description text using the %e placeholder.<br />
<br />
{{NOTE|To make your changes take effect after adding or modifying the events files you must do a <tt>'''kill -SIGHUP `pidof acpid`'''</tt>}}.<br />
<br />
Our example <tt>/etc/acpi/actions/sleep.sh</tt> script looks as follows:<br />
<br />
#!/bin/sh<br />
<br />
# if launched through a lid event and lid is open, do nothing<br />
echo "$1" | grep "button/lid" && grep -q open /proc/acpi/button/lid/LID/state && exit 0<br />
<br />
# remove USB 1.1 driver<br />
rmmod uhci_hcd<br />
<br />
# sync filesystem and clock<br />
sync<br />
/sbin/hwclock --systohc<br />
<br />
# switch to console<br />
FGCONSOLE=`fgconsole`<br />
chvt 6<br />
/usr/sbin/radeontool light off<br />
<br />
# go to sleep<br />
echo -n "mem" > /sys/power/state<br />
<br />
# readjust the clock (it might be off a bit after suspend)<br />
/sbin/hwclock --adjust<br />
/sbin/hwclock --hctosys<br />
<br />
# reload USB 1.1 driver<br />
modprobe uhci_hcd<br />
<br />
# turn on the backlight and switch back to X<br />
radeontool light on<br />
chvt $FGCONSOLE<br />
<br />
The lid generates an event for both opening and closing thus requiring<br />
that we check it's state and only act if it's closed.<br />
<br />
There have been problems encountered with the USB devices not working properly after a resume from suspend.<br />
To circumvent those we remove the USB driver prior to suspend and reload it afterwards.<br />
<br />
Note that the <code>echo -n "mem" > /sys/power/state<br />
</code> line does not return until we are revived. So there is<br />
only one event generated and there is no need to check the state of<br />
anything.<br />
<br />
The console switching code in this script is a special solution for<br />
[[Problem with LCD backlight remaining on during ACPI sleep|a problem where the backlight doesn't switch off]]<br />
on the {{T30}} and some other models. Before going to sleep, these models switch to console mode which causes the<br />
backlight to come back on. So we preemptively switch to console mode and turn off the backlight using [[radeontool]]<br />
before going to sleep.<br />
{{NOTE|If your display doesn't come back on resume, look [[Problem with display remaining black after resume|here]].}}<br />
<br />
<br />
[[Category:570]] [[Category:570E]] [[Category:A20m]] [[Category:A20p]] [[Category:A20m]] [[Category:A20p]] [[Category:A21e]] [[Category:A21m]] [[Category:A21p]] [[Category:A22e]] [[Category:A22m]] [[Category:A22p]] [[Category:G40]] [[Category:G41]] [[Category:R30]] [[Category:R31]] [[Category:R32]] [[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:X20]] [[Category:X21]] [[Category:X22]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]]</div>145.253.208.115https://www.thinkwiki.org/w/index.php?title=How_to_install_the_IBM_Ultracam_II_driver&diff=6191How to install the IBM Ultracam II driver2005-06-14T12:12:19Z<p>145.253.208.115: </p>
<hr />
<div>=How to make the IBM UltraCam II work under Linux:=<br />
<br />
1. First you have to get the [[Ultracampatch | kernel patch for the ultracam]].<br />
<br />
: The patch is for Kernel 2.4.20, so if you are using any other 2.4 series kernel you might have to adjust the patch to work.<br />
: On 2.6 the structure of the usb source tree changed a lot, a patch is available for 2.6.10 at: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=111802180804300&w=4<br />
<br />
2. Change to the drivers directory in the kernel source tree:<br />
cd /lib/modules/'uname -r'/build/drivers<br />
<br />
3. Apply the patch:<br />
patch -p0 -i <pfad zu dem gespeicherten patch-file>.<br />
: If the patch was successful, you should see the following:<br />
patching file usb/Config.in<br />
patching file usb/Makefile<br />
patching file usb/ultracam.c<br />
patching file usb/usbvideo.c<br />
<br />
4. Go up one level to the kernel source root:<br />
cd ..<br />
<br />
5. Configure the kernel:<br />
make menuconfig<br />
<br />
6. Activate the following Options as modules (set to <M>):<br />
Multimedia devices -> Video For Linux<br />
USB support -> Support for USB<br />
USB support -> Preliminary USB device filesystem (auf [*])<br />
USB support -> UHCI Alternate Driver (JE) support<br />
USB support -> USB IBM Ultraport II Camera support<br />
: In case some of them should already be activated (<*> oder <M>), just let them as they are.<br />
: Exit the configuration and save your settings.<br />
<br />
7. Recompile the kernel modules: make dep && make modules modules_install && depmod -ae.<br />
<br />
: NOTE: If you are using non standard kernel modules they have to be recompiled afterwards as well.<br />
<br />
8. Now you can do<br />
modprobe ultracam<br />
and launch "xawtv".<br />
<br />
If everything works, you should see yourself now. The driver is quite unstable and you might have to unload and reload the ultracam module every now and then.<br />
<br />
[[Category:A20m]] [[Category:A20p]] [[Category:A21e]] [[Category:A21m]] [[Category:A21p]] [[Category:A22e]] [[Category:A22m]] [[Category:A22p]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:X20]] [[Category:X21]] [[Category:X22]] [[Category:X23]] [[Category:X24]]</div>145.253.208.115https://www.thinkwiki.org/w/index.php?title=How_to_install_the_IBM_Ultracam_II_driver&diff=5680How to install the IBM Ultracam II driver2005-06-14T12:11:54Z<p>145.253.208.115: /* How to make the IBM UltraCam II work under Linux: */</p>
<hr />
<div>=How to make the IBM UltraCam II work under Linux:=<br />
<br />
1. First you have to get the [[Ultracampatch | kernel patch for the ultracam]].<br />
<br />
: The patch is for Kernel 2.4.20, so if you are using any other 2.4 series kernel you might have to adjust the patch to work.<br />
: On 2.6 the structure of the usb source tree changed a lot, a patch is available for 2.6.10 at:<br />
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=111802180804300&w=4<br />
<br />
2. Change to the drivers directory in the kernel source tree:<br />
cd /lib/modules/'uname -r'/build/drivers<br />
<br />
3. Apply the patch:<br />
patch -p0 -i <pfad zu dem gespeicherten patch-file>.<br />
: If the patch was successful, you should see the following:<br />
patching file usb/Config.in<br />
patching file usb/Makefile<br />
patching file usb/ultracam.c<br />
patching file usb/usbvideo.c<br />
<br />
4. Go up one level to the kernel source root:<br />
cd ..<br />
<br />
5. Configure the kernel:<br />
make menuconfig<br />
<br />
6. Activate the following Options as modules (set to <M>):<br />
Multimedia devices -> Video For Linux<br />
USB support -> Support for USB<br />
USB support -> Preliminary USB device filesystem (auf [*])<br />
USB support -> UHCI Alternate Driver (JE) support<br />
USB support -> USB IBM Ultraport II Camera support<br />
: In case some of them should already be activated (<*> oder <M>), just let them as they are.<br />
: Exit the configuration and save your settings.<br />
<br />
7. Recompile the kernel modules: make dep && make modules modules_install && depmod -ae.<br />
<br />
: NOTE: If you are using non standard kernel modules they have to be recompiled afterwards as well.<br />
<br />
8. Now you can do<br />
modprobe ultracam<br />
and launch "xawtv".<br />
<br />
If everything works, you should see yourself now. The driver is quite unstable and you might have to unload and reload the ultracam module every now and then.<br />
<br />
[[Category:A20m]] [[Category:A20p]] [[Category:A21e]] [[Category:A21m]] [[Category:A21p]] [[Category:A22e]] [[Category:A22m]] [[Category:A22p]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:X20]] [[Category:X21]] [[Category:X22]] [[Category:X23]] [[Category:X24]]</div>145.253.208.115