Monthly Archives: May 2015

Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

Posted on by

An einem unserer Entwicklungssysteme nutzte ich bisher zwei 24 Zoll IPS-Schirme mit einer Auflösung von 1920×1200. Vor einigen Monaten hatte ich zudem meine alte Nvidia GTX 460 Grafikkarte gegen eine GTX 750 TI von Gigabyte ausgetauscht. Letztere bietet aus meiner Sicht einen annehmbaren Kompromiss zwischen 2D/3D-Leistung und Preis – zumal ich kein Interesse an PC-Spielen habe. Die Umstellung ging problemlos – soweit man mal von kleineren Problemen der proprietären Nvidia-Treiber in der aktuellen KDE 4.14 / KDE 5 Umgebung absieht (siehe die Off Topic Anmerkungen am Ende des Artikels).

Nachfolgend möchte ich darstellen, dass und wie man diese Konfiguration unter Linux um einen DELL U2515H in dessen nativer Auflösung erweitern kann. Insgesamt ergibt sich damit ein Linux-System (in meinem Fall unter Opensuse 13.2 und KDE) mit 3 Schirmen und einer (virtuellen Xinerama) Screenbreite von 6400 Pixeln.

kde_3_screens_2

Verfügbare Schnittstellen der Gigabyte GTX750 GTI

Gigabytes GTX 750 TI hat 2 DVI- und 2 HDMI-Schnittstellen, aber leider keinen Display Port. 4K Auflösung wird auch nur in Spezialkonfigurationen unterstützt – die Schirme müssen hierzu einen bestimmten Modus mitmachen. Eine Auflösung von 2560×1440 bringt die Karte laut Spezifikation aber sehr wohl zustande – zumindest an einem Schirm. Über das Fehlen einer Display-Port Schnittstelle hatte ich beim Kauf nicht weiter nachgedacht. Da immer mehr Schirme jedoch keine DVI-Schnittstelle mehr anbieten, ist das ein Punkt, der künftig meine Graka-Entscheidungen sehr viel stärker beeinflussen wird.

25 Zoll Schirm Dell U2515H

Jetzt hat einer meiner älteren Schirme – ein von mir geliebter alter Samsung 244T mit S-PVA Panel (Samsung hat danach nie wieder so gute Monitore gebaut!) – eine Macke: Der Schirm kommt nach einer längeren Abschalt-Phase durch KDE’s Powersaving Funktionen u.U. nicht mehr hoch. Wir hatten solche Probleme schon früher – vermutete Ursache sind defekte oder altersmüde Kondensatoren der Schalt-Elektronik des Schirms. Das Panel selbst ist völlig OK. Zu anderen möglichen Ursachen s. die Off Topic Anmerkung weiter unten. Eine weitere Reparatur des Samsung lohnt sich jedenfalls nicht. Grund genug, über einen neuen Schirm für meinen Linux-Arbeitsplatz nachzudenken.

Die Wahl fiel nach Internet-Recherchen auf einen Dell U2515H. Dieser 25 Zoll (!) Schirm hat ein IPS AH Panel mit einer nativen Auflösung von 2560×1440 Pixeln und kostet z.Z. um die 300 Euro. Ich habe mir den Schirm bei einem netten Händler (Schwanthaler-Computer) gegen einen Aufpreis vorführen lassen und war recht angetan. Ein paar Stichpunkte:

Der hohe Kontrast der Standardeinstellung ist mir persönlich zu intensiv – aber das kann man sehr gut manuell nachregeln – ebenso wie die Helligkeit. Die Winkelabhängigkeit von Helligkeit, Farbtreue, Kontrast des Bildes halten sich in den Grenzen dessen, was man von einem besseren IPS-Panel erwarten kann. (Mit der Qualität eines PVA oder MVA Panels kann sich ein IPS Schirm in diesem Punkt von Haus aus nicht messen.) Ja – es gibt auch einen typischen IPS Glow – in vertikaler Richtung ausgeprägter als in horizontaler – besonders wenn man von unten nach oben auf den Schirm sieht. Es ist ein flächiger, weißlicher Effekt – er führt aber interessanterweise nicht zu Farbverfälschungen, wie ich sie schon bei anderen Schirmen gesehen habe. Der Effekt ist subjektiv geringer und auch homogener als bei einem ASUS 248PBQ.

Die Entspiegelung des U2515H hätte für meine Gefühl besser sein können; eine helle Tischplatte oder ein eigenes weißes Hemd wird im Schirm etwas verwaschen wahrnehmbar sein. Die Entspiegelung ist geringer als bei aktuellen ASUS Schirmen. Aber das ist vielleicht Geschmackssache und nicht jeder mag die Körnigkeit stark entspiegelter Schirme. Die Homogenität der Ausleuchtung ist zumindest bei meinem Exemplar recht gut; da habe ich im Netz schon anderes gelesen. Subjektiv meine ich, einen minimalen Helligkeitsabfall zu den Rändern links und rechts feststellen zu können – hier schlägt vielleicht aber auch schon die Winkelabhängigkeit des Bildes in Kombination mit der Breite des Schirms zu.

An die Bedienlogik und die Touch-Tasten konnte ich mich relativ schnell gewöhnen. Die manuelle Farbregelung ist für mein Gefühl zu sensibel – hier schlagen nichtlineare Effekte schnell zu – aber es ist durchaus möglich, die Farbeinstellungen manuell allein über die Steuerungsfunktionen des Schirms selbst anzupassen. (Eine echte Kalibrierung ersetzt das nicht). Schlechter als bei aktuellen Asus-Schirmen im Bereich zwischen 300 und 500 Euro ist die manuelle Bild-Regelung des Dell in keinem Fall – eher besser. Zudem bietet Nvidias Applikation “Nvidia X server Settings” für Linux die Möglichkeit pro Schirm individuelle Einstellungen der Farbkanäle vorzunehmen. Ein Manko des DELL : Eine stufenlose Gamma-Regelung ist leider nicht möglich. Hier muss man auf Möglichkeiten der Grafikkarte zurückgreifen.

Relativ beeindruckend ist die Darstellung von Grauverläufen in Testbildern. Ich konnte bei normalem Kontrast bislang keinerlei Streifigkeit erkennen. Bzgl. Spielen habe ich nur Alien Arena in verschiedenen Auflösungen angesehen. Kein akutes Problem erkennbar. Ich habe aber keine Ansprüche und spiele aus Zeitmangel so gut wie nie. Videos: Von meiner Seite kein Problem erkennbar.

Ausführliche Review-Berichte zum U2515H von professionellen Testern findet man z.B. hier:
http://www.tftcentral.co.uk/ reviews/ dell_u2515h.htm
http://www.prad.de/ new/ monitore/ test/ 2015/ test-dell-u2515h-teil10.html

Kein DVI-Anschluss für den Dell U2515H – funktioniert HDMI mit einer Auflösung von 2560×1440?

Das größte Problem stellte für mich bei der Kaufentscheidung die hohe Auflösung in Kombination mit der Tatsache dar, dass der DELL U2515H nur HDMI und Display-Port-Anschlüsse, aber keinen DVI-Eingang besitzt. Im Internet hatte ich vorab über erhebliche Probleme anderer Leute gelesen, die hohe Auflösung von 2560×1440 bei diesem und vergleichbaren Schirmen über HDMI (gem. 1.4 Standard) überhaupt zum Laufen zu bringen – und das an Arbeitsplätzen mit nur einem Schirm. Wenn überhaupt, so klappte das meist nur mit reduzierter Bildwiederholrate von 55 Hz oder gar nur 30 Hz – unter Linux wie unter MS Win. Weniger Probleme hatten Anwender dagegen bei Verwendung eines Displayports – aber genau einen solchen Anschluss bietet nun die Gigabyte GTX 750 TI nicht. Da sah ich doch ein erhebliches Risiko auf mich zukommen.

Dell 2515H parallel mit zwei 1920×1200 Karten an der GTX 750 TI unter Linux?

Meine Ansprüche waren aber noch höher: Ich wollte den Schirm in nativer Auflösung und in Kombination mit mindestens einem, besser aber zwei 1920×1200 Schirmen an der GTX 750 TI zum Laufen unter Linux bringen. Die gute Nachricht ist: Ja, das geht ! Voraussetzungen sind:

  • Ein gutes HDMI Kabel. Ich habe mir ein ca. 13 Euro teures Delock Kabel geleistet, das gem. Spezifikation u.a. Übertragungsraten von bis zu 10,2 Gb/s und Auflösungen bis zu 4096×2160 px unterstützen soll.
  • Der Einsatz des proprietären Nvidia-Treibers >= NVIDIA-Linux-x86_64-346.47
  • Etwas Experimentierwillen und der Einsatz des proprietären Nvidia-Treibers. (Ich sollte besser sagen: Mit dem proprietären Treiber geht es sicher. Mit dem nouveau-Treiber habe ich es bisher schlicht nicht getestet. Es mag damit ggf. auch funktionieren.)

Mein erster Versuch, auch nur einen weiteren Schirm zusammen mit dem DELL U2515H zum Laufen zu bringen, scheiterten allerdings. Ich nutzte und nutze zur Grundeinstellung Nvidias “NVIDIA X SERVER Settings”-Applikation und dort den Punkt “X Server Display Configuration”.

Ich schaffte es im ersten Anlauf einfach nicht, den Dell 2515H an der ersten HDMI Schnittstelle der Graka in Kombination mit einem ASUS PB248Q am ersten DVI-Anschluss so zum Laufen zu bringen, dass ich die Maximalauflösung am Dell bei 60 Hz erhalten hätte. Möglich waren nur Auflösungen von 2048×1152 oder 1920×1200. Die höchste Auflösung 2560×1440 wurde in der “Nvidia X Server Settings”-Applikation (unter KDE) gar nicht angeboten. Auch die Einstellmöglichkeiten unter den
“KDE Systemeinstellungen >> Hardware >> Anzeige und Monitor”
boten die maximale Auflösung nicht an. Ich kann nur sagen: Lasst euch dadurch nicht entmutigen. Was bei mir half, waren dann folgende Schritte:

Raus aus KDE auf ein Konsolterminal >> init 3 >> Neuinstallation des proprietären Nvidia-Treibers bei angeschlossenem Dell-Schirm am ersten HDMI-Ausgang der Graka (und den beiden anderen 1920×1200 Monitoren an den 2 DVI-Ausgängen) >> Reboot >> Start KDE >> Nvidia-X-Server-Einstellung => – und siehe da: Die volle Auflösung wird seitdem angeboten.

nvidia_screens

Auch unter KDE’s “systemsettings” wird die Maximalauflösung korrekt wiedergegeben:

kde_screens_2

Bilder

Im Moment sieht mein resultierendes physikalisches Screen-Layout wie folgt aus:

kde_3_screens_live_1200

Das nachfolgende Bild stellt dagegen einen Screenshot – erzeugt mit Ksnapshot dar:

kde_3_screens_1

Dort bleibt links und rechts ein schwarzer Streifen am unteren Bildrand. Der findet sich auf den Schirmen selbst natürlich nicht (s.o.). Auf die Unterschiede in den bildlichen Darstellungen würde ich nicht zuviel geben – die Kamera sieht anders als das menschliche Auge und die Schirme sind unterschiedlich eingestellt. Subjektiv finde ich, dass der Dell kleine Farbnuancen und filigrane Bildstrukturen bei etwas heruntergeregeltem Kontrast sehr gut wiedergibt.

Simple xorg.conf

Die xorg.conf, die der proprietäre Nvidia-treiber erzeugt, hat folgenden Inhalt:

xorg.conf

# nvidia-xconfig: X 
configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 346.59  (buildmeister@swio-display-x86-rhel47-04)  Tue Mar 31 14:42:07 PDT 2015

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 346.47  (buildmeister@swio-display-x86-rhel47-01)  Thu Feb 19 19:18:25 PST 2015

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Ancor Communications Inc PB248"
    HorizSync       30.0 - 83.0
    VertRefresh     50.0 - 61.0
    Option         "DPMS" "false"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 750 Ti"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DVI-I-1: 1920x1200_60 +0+0, DVI-D-0: 1920x1200_60 +1920+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Der dort erscheinende Ancor Schirm – eigentlich ein ASUS PB248Q – ist der primäre Schirm; die anderen Schirme (Dell U5215, Samsung 244T) sind über die xinerama-Konfiguration in den nahtlosen “Screen0” mit einer Breite von 6400 px integriert.

Keine niedrige Taktung der Grafikkarte bei 3 Schirmen

Wenn jemand eine ähnliche Konfiguration mit drei Schirmen ausprobieren will, wird er schnell feststellen, dass die Grafikkarte auch bei Auswahl eines adaptiven Leistungsmodus nicht mehr in den Level 0 mit geringer Taktung zurückschaltet. Sie arbeitet immer im oberen Taktungsbereich für maximale Performance. Nachfolgend das Bild zum “Powermizer”-Eintrag des Nvidia-Tools:

nvidia_screens_2

Dies ist bei zwei Schirmen noch anders. Da reicht eine geringere Leistungsfähigkeit. Woran immer der Nvidia-Treiber den Leistungsbedarf misst und welchen Grenzwert er dabei für die Höhertaktung beachtet. Die Lüfter-RPM steigt aber auch bei der höheren Taktung nur unwesentlich an. Im Office- und Entwicklungseinsatz, bei einer aktuellen Zimmertemperatur von ca. 26 Grad Celsius und geschlossenem Gehäuse liegen die GPU Temperatur bei ca. 41 Grad und die Lüfter RPM-Werten um die 1650 (Speed 33%).

Die hohe Auflösung des Dell U2515H – wo macht das was aus ?

Nun noch ein paar Worte zu den unterschiedlichen Auflösungen – besser zu der extrem hohen Auflösung des Dell
unter 25 Zoll. Das erste was hier zu sagen ist, ist dass ein 25 Zoll 16:9 Schirm in der Höhe etwa 1 cm kleiner ist als ein konventioneller 4:3 24 Zoll Schirm. In der Breite gewinnt man dagegen knapp 3.5 cm. In der physikalischen Ausdehnung fällt der Unterschied zu einem 4:3 24 Zoll Schirm also nicht sofort ins Auge (s. auch das Bilder zu den Schirmen oben). Demzufolge hat die doch deutlich höhere Auflösung bei gleicher Schrifteneinstellung spürbare Auswirkungen auf die Font-Darstellung. Das Bild ist gestochen scharf – aber die Schriften sind erwartungsgemäß deutlich kleiner als auf den 24 Zöllern mit 1920×1200. Nun sehe ich auf die Schirmdistanz auch in meinem Alter noch recht gut. Dennoch : Kleine Fonts sind anstrengender als große. Leider bietet KDE bisher keine Möglichkeit, Schriftfonts schirmspezifisch einzustellen. Wo kommt das beim Arbeiten unter Linux zum Tragen?

Auf der Desktop-Oberfläche kann man innerhalb der eingesetzten Plasmoide in vielen Fällen bzgl. Symbol- und Schriftgröße nachregeln. Kein Problem macht auch das Arbeiten mit Dokumenten oder dem Browser – hier kann man nahtlos und individuell skalieren.

Am meisten Probleme bereitet mir zur Zeit eher Eclipse. Unter Luna funktionieren die in
http://stackoverflow.com/ questions/ 6948374/ how-to-change-font-size-quickly-in-eclipse
angegebenen Tools für PDT nicht. Selbts wenn sie es täten – eine individuelle Font-Regelung pro geöffnetem Eclipse-Fenster gibt es zur Zeit leider genausowenig wie ein Reinzoomen in den Code eines Eclipse Fensters. Man muss also Schriftgrößen für die Code-Darstellung wählen, so dass man in den Eclipse-Fenstern, die am Dell angezeigt werden, noch gut lesen kann, auf den anderen Schirmen aber nicht zuviel Platz verliert. Mit 12-er Fonts kann ich im Moment ganz gut leben. Wirklich komfortabel ist das aber nicht. Der Request bzw. Bug zu Eclipse, in dem eine Editor- und Window-spezifische Zoom-Funktion gewünscht wird, hat nun leider schon einige Zeit am Buckel, ohne dass etwas Greifbares passiert wäre.

Nachtrag, 14.12.2015:
Die Nvidia GTX 750 TI funktioniert auch mit 2 Dell U2515H per HDMI und einem 1920×1200 Schirm per DVI. Siehe:
Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm

Off Topic Anmerkung 1 – Nividia Treiber und Tearing

Ich habe auf allen unseren Opensuse-Systemen unter KDE immer wieder ein Problem mit den proprietären Drivern von Nvidia, die das Tearing der Kanten von schnell bewegten Fenstern betreffen nach dem KDE-Start. So erfordert eine tearing-freie Darstellung oftmals einen manuellen Switch in den OpenGL-Einstellung der KDE “systemsettings” (z.B. vom Raster-Modus auf Native oder auch von OpenGL 2.0 auf OpenGL 3.1). Den Einstellungswechsel man danach sofort wieder rückgängig machen. Es ist, als ob die Karte sich erst dann wirklich auf die vertikale Synchronisierungsfrequenz einstellt, obwohl das in den KDE-Einstellungen eigentlich bereits vorgegeben sein mag. Initial beim KDE-Start ist vollständige Tearing-Freiheit jedenfalls nicht für alle Typen von Fenstern gegeben. Zumindest nicht so, wie es ein (nachfolgender) manueller Einstellungswechsel bewirkt.

Ergänzung, 14.12.2015:
Der beschriebene Effekt liegt an einer unzureichenden Buffer-Konfiguration, die man über die xorg.conf beheben kann. Siehe:
Nvidia Treiber, KDE-Plasma-Desktop 4.14, Tearing-Effekt: Triple Buffering einschalten!

Off Topic Anmerkung 2 – Probleme mit Samsung T244 nach Screen Abschaltung durch KDE’s Energiesparfunktionen

Zwei unserer älteren Samsung 244T Schirme haben beim Einsatz an Linux-Systemen unter KDE bereits das Problem bekommen, dass sie eine Weile (ca. 1 Stunde) nach Abschaltung durch die KDE Stromsparfunktionen nicht mehr hochzubekommen sind. So flackert auch die Statusleuchte danach unkontrolliert. In der Phase bis dahin blinkt de Leuchte regulär. Einer der Schirme wurde daraufhin bereits zweimal repariert. Der Schirm, der das Problem aktuell wieder hat, ist nur nach längerem Abschalten, einem Reset und ein paar Tricks wieder zum Leben zu erwecken. Die Probleme liegen in der Schaltelektronik, nicht am Panel selbst. Es tritt übrigens nicht auf, wenn man den PC regulär runterfährt. Auch dann schaltet sich der Schirm ab – er schaltet sich dann aber beim Hochfahren des PCs auch wieder regulär an. Wegen des Alters und des Recovery nach längerer Abschaltzeit mag man natürlich an defekte Kondensatoren denken.

Ehrlich gesagt, glaube ich persönlich allerdings nicht, dass diese Probleme ausschließlich mit der Altersschwäche von Kondensatoren zu tun haben. Ich hege den Verdacht, dass hier auch eine fehlerhafte oder wiedersprüchliche Kombination eigener Stromsparfunktionen der Nvidia-Karten-Treiber mit Signalen der KDE-Stromsparfunktionen an Schirme, die nicht den aktuellen sondern älteren TCO-Normen gehorchen, verursacht werden. Diese Gefühl hängt mit folgenden Beobachtungen zusammen: Der Übergang von einem normalen Abschaltzustand des Schirms in einen unkontrollierten Zustand geschehen offenbar abrupt nach einem definierten Zeitintervall. Und ich habe ein System, an dem KDEs Screen Powersaving Funktionen nie aktiviert wurden – der dortige 244T hat null Probleme – obwohl er 1 Jahr älter als die anderen ist. Aber dass so eine Gefühl eine echte Grundlage hat, kann man nicht oder nur sehr schwer beweisen …

Der neue Dell tut jedenfalls bzgl. der Stromsparfunktionen genau das, was er soll.

 

CSV file upload with ZIP containers, jQuery, Ajax and PHP 5.4 progress tracking – III

Posted on by

In the first 2 articles of this series I described a bit of what had to be done on the JS/jQuery client side to trigger the first phase (Phase I) of an Ajax controlled file upload (here: of a Zip container file). See:

CSV file upload with ZIP containers, jQuery, Ajax and PHP 5.4 progress tracking – I
CSV file upload with ZIP containers, jQuery, Ajax and PHP 5.4 progress tracking – II

In this third article, we take a first glimpse at what has to be done on the server side – in our case in the PHP 5.4 target program of our Ajax request. There are of course very many and different ways to deal with the initial treatment of an uploaded file. What I normally do is to create a “File_Handler” object based on a class which encapsulates and provides all required methods. However, for the sake of a better understandability the code fragments presented below do not always follow a stringent OO line of code development and are sometimes very basic. We only show code elements that are of fundamental importance.

The reader may remember that the method of our Javascript CtrlO for controlling the upload form (see the last article) called a PHP target program named

handle_uploaded_init_files.php5?file

.
The attached GET-parameter distinguishes the first phase of the upload from several following phases. One of the initial things our PHP program should do is to open/access a PHP session, to start PHP output buffering and to check whether the $_GET element $_GET[‘file’] exists:

Excerpts from the PHP target program of Phase I – handle_uploaded_init_files.php5:

	$time_0 = microtime(true); 
	session_start();
	ob_start(); 
	....
	// Deal with phase I of the upload 
	if ( isset( $_GET['file'] )) {
		...
		$response = handle_transferred_file(); 
		ob_end_clean(); 
		echo $response;  
	}

(Side remark: Note that the attached Get parameter is nevertheless transferred via the POST mechanism of HTTP !)

$response represents a prepared encoded JSON-Object which is sent back to the JS-Ajax-client at the end of the program. By the “if”-statement we just distinguish the actions of Phase I from later phases where we deal with each file transferred in our large Zip-container file. The main work for our phase I is in our example obviously done inside a function “handle_transferred_file()”.

The use of “session_start()” seems to be quite reasonable. The PHP manual
http://php.net/manual/en/session.upload-progress.php
describes that upload progress information is supplied via $_SESSION. This is just the way the progress tracking of PHP 5.4 works!

However, we shall come back to this point at the bottom of this article and we shall see that things are not that simple. But, we may use the $_SESSION array also for keeping other interesting information. Anyway, using a PHP-session (=opening/accessing a session) will do no harm here.

But why do we need ob_start() ?
In the last article of our series the Ajax answer to the client was requested to have the form of a JSON object. So, our Ajax driven client program expects exactly one information stream in the form of a JSON object. However, if your own PHP code accidentally produces strings by executing some echo, print or print_r statements this rule will be violated. The client will receive the first PHP output as the expected Ajax JSON answer and
will not be able to parse it. This would result in an Ajax client error! Another source of unwanted and not JSON encoded output may come from the PHP engine itself which may create warnings and error messages during code execution. Therefore, it is a good habit to gather all such information in the output buffer and put it eventually as a special string element (as “system_mgs”) of an array which we shall encode as the final JSON object. See below.

A function and an array for producing the JSON answer of upload Phase I

Let us now turn to our function dealing with phase I. In our simple test case it basically does 2 things:

  • It creates a singleton object for performing progress tracking and later some file operations. This object then does the necessary things itself and produces an array which we in our example receive in the variable $response.
  • It enriches the response array with some information and encodes it as a JSON object.

That we have split the required actions into these steps is again more for the sake of illustration purposes. 

function handle_transferred_file() {
	...
	// Some local variables 
	$ctrl_msg = '';
	
	// Includes
	require_once $my_include_path . 'class_file_handler.php5';
	require_once $my_include_path . 'class_file_handler_params.php5';
		
	// Parameter Singleton with parameters to control the file handling  	
	$F_Params = new FileHandlerParams(); 
		
	// File handler object (singleton) 	
	$F_Handler = new Basic_Class_File_Handler( $F_Params );
	if (isset($FCheck->msg)) {
		$ctrl_msg .= "\r\nFCheck initialized";
		$ctrl_msg .= "\r\nInitial msg = " . $FCheck->msg;
	}

	// Transfer the file to its directory location and unzip its contents 
	$F_Handler->check_and_save_uploaded_file(); 

	// Required time and response enrichment 		
	$time_f = microtime(true);
	$dtime_f = $time_f - $time_0;
	$F_Handler->ay_ajax_response_1["transfer_time"] = $dtime_f;
	
	// Response enrichment by system messages form the output buffer 
	$F_Handler->ay_ajax_response_1['sys_msg'] .= ob_get_contents(); 
	
	// return JSON encoded array 
	$response =json_encode($F_Handler->ay_ajax_response_1);
	return $response; 
}

This is fairly simple to understand: We load some class definitions – one for the handling of the file transferred into the $_FILE superglobal and one with a bunch of parameters. We then create a singleton object $F_Handler which does most of the required actions of Phase I. Its property “$F_Handler->ay_ajax_response_1” obviously is an array which is enriched by the contents of the PHP output buffer and some time information (just for illustration purposes). This array is eventually encoded as the required JSON answer object.

Typically the element $F_Handler->ay_ajax_response_1[‘sys_msg’] is used on the client side for tests only via the console.log() statement of Javascript.

Possible parameters of the File Handler object $F_Handler

What kind of parameters may be required? E.g.: the path of the directory where we want to save our transferred Zip-file and/or its contents on the server. The expected file ending. The maximum file size allowed. A parameter defining whether we really want to check the progress of the upload. The reader may think about more useful parameters.

In our example such parameters can be gathered and maintained via properties of the class “FileHandlerParams”. The F_Handler object may extract them from the respective Parameter object given as an argument to its constructor, and write them afterward into internal property variables.

Main elements of a Basic_File_Handler class

The “Basic_File_Handler_Class of our example may contain the following methods: 

class Basic_Class_File_Handler {
	
	var $file_key; 		// Key of uploaded file in $_FILES[$key]
	var $file_name = ''; 	// Name of present file (uploaded or part of a pipeline)  
	var $file_mime = ''; 	// Mime-Type of present file 
	var $file_end = ''; 	// Suffix (ending) of present file 
	
	var $file_expected_end = array("csv", "zip");	// Allowed suffixes of the transferred file 
	
	var $file_size; 		// Size of present file 
	var $max_file_size = 100000000;	// Maximum allowed size 100MBytes
	var $check_progress = 0; 	// Check progress by means of PHP 5.4  ?
	var $sess_key_progress = ''; 	// The key of $_SESSION where to find upload progress infos 
	
	// Upload dir 
	var $upl_dir;  			// The given short name of the dir without root path 
	var $target_dir; 		// The full path of the target dir on the PHP server 

	var $ziel_file_name_oe; 	// Target name of file without ending and "."
	var $ziel_file_name; 		// Full target name of file 
	var $ziel_file_pfad; 		// Full target path relative to web domain dir  
	var $ziel_file_pfad_dom;	// Full target path rel. to PHP root on the server 

	var $root;   			// rel. path of present application to PHP application root
	var domain_root;		// rel. path of present application to Web domain root 
	
	var $upload_success = 0; 
	var $msg = ''; 
	var $sys_msg = ''; 
	var $err = 0; 
	var $err_msg = '';  
	
	// zip file info 
	var $num_extracted_files = 1; 
	var $file_pipeline = 0;  // will be set to 1 if the zip-file contains more than 1 files 
	
	// Ajax response array 
	var $ay_ajax_response_1 = array();   // For phase 1 	
	
	.....
			
// Main methods 
// -----------
	// constructor 
	function __construct($Params)  {
 		...
	}

	// function to check properties of the uploaded file and save it in a target directory on the server  
	function check_and_save_uploaded_file() {
		....
	}		
	
	// Method to prepare Ajax (JSON) response array for phase 1 of upload 
	function prepare_ajax_response_phase_1() {
		...
	}
		
	// Check existence of transferred file in $_FILES
	function check_file_existence_and_props() {
		...
	}
	
	// Check suffix = file ending 
	function get_and_check_file_suffix() {
		...
	}
	
	// Check File_Size
	function check_file_size() {
		...
	}
		
	// Delete all existing files in the upload dir 
	function delete_files_from_upload_dir() {
		...
	}
	
	// Move the uploaded file or the content files of an uploaded zip file to the target directory 
	function move_file_to_upload_dir() {
		...
	}
	
	// function to determine the number of extracted files and the name of the next file to handle  
	function determine_num_files_and_next_file_name() {
		...
	}
	
	// Method to handle a zip archive 
	function handle_zip_archive( $dest_file, $dest_dir) {
		...
	}
	...
	...

// End of class definition  
}

We shall look at some details of these methods in the articles to come.

The key to session information about the progress of the ongoing upload progress

The constructor of our Basic_File_Handler class gets the task to read in parameters. In addition we use it here and try to retrieve some (initial?) progress information from the $_SESSION array – just for learning purposes. Actually, we shall see that this trial will NOT give us any progress information at all or only a trivial one. 

function __construct($Params_ext) {
	
	// read external parameters 
	$num_args = func_num_args(); 
	if (num_args == 1 ) {
		$Params = func_get_arg(0);
		if ( is_object($Params) && get_class($Params) == "FileHandlerParams" ) {
			$this->file_key  = $Params->file_key; 
			if( is_array($Params->file_types) && count($Params->file_type) > 0 ) {
				$this->file_type = $Params->file_types; 
			}
			$this->upl_dir 	= $Params->upload_dir . "/";
			$this->max_file_size	= $Params->max_file_size; 
			$this->check_progress= $Params->check_progress; 
		}
	}
	// Error treatment 
	else {
		...
		$this->ay_ajax_response_1[sys_msg] .= "\r\nWrong Parameter object!"; 
	}		
		
	// Test the progress information in $_SESSION (Is this reasonable here ???) 
	if ( $this->check_progress == 1 ) {
		// Get the required string end for the key of progress info in the $_SESSION array
		// This information was delivered via $_POST by the Ajax client program 
		$this->sess_key_progress = '';
		$key_POST = ini_get("session.upload_progress.name");
		if (isset( $_POST[$key_POST] ) ) {
			$this->sess_key_progress .= ini_get("session.upload_progress.prefix"). $_POST[$key_POST];
			$this->sys_msg .= "<br>sess_key_progress = " . $this->sess_key_progress;  
			$this->ay_ajax_response_1['sess_key_progress'] = $this->sess_key_progress;  
			$_SESSION['progress_key'] = $this->sess_key_progress;
			
			// Write a test value into a special Session variable 
			$current = -1;
			if (isset($_SESSION[$this->sess_key_progress]) && !empty($_SESSION[$this->sess_key_progress])) {
				$current 	= $_SESSION[$this->sess_key_progress]["bytes_processed"];
				$total 		= $_SESSION[$this->sess_key_progress]["content_length"];
				$current	= ($current < $total) ? ceil($current / $total * 100) : 100;
			}
			$this->sys_msg .= "<br>Initial progress value of the file transfer was " . $current; 
		}
	}	
		
	// set the TARGET DIR for saving the file
	$this->target_dir 	= $this->root . $this->upl_dir;
			
	return;
}

 
$this->check_progress is set by the parameters transferred.

Note that progress tracking and the delivery of related information in the $_SESSION array requires the following setting in the php.ini file (“/etc/php5/apache2/php.ini” on Opensuse)

; Enable upload progress tracking in $_SESSION
; http://php.net/session.upload-progress.enabled
session.upload_progress.enabled = On

In the lower part of the PHP code we see how the key for the element of the $_SESSION array which contains information about the upload progress is composed:

We first need a parameter from the php.ini file which we read by ini_get(“session.upload_progress.prefix”). Then we need another parameter of our php.ini file on the server which gives us a special index of the $_POST array:
$key_POST = ini_get(“session.upload_progress.name”).
This index points to an element of the $_POST array which (hopefully) contains a unique identifier of our presently progressing upload process. We must submit this identifier by our Ajax client method initiating the whole file transfer; see the last article in this series. Eventually, we combine both pieces of information to get the index ($this->sess_key_progress) of an element of the $_SESSION array which will contain progress information about our upload.

In the code above we write this information into our output array as part of an Ajax response.

When and how is the progress information
available in the $_SESSION array?

The next code section then uses our composed key to read a test status value of the upload (at the point of code execution) from the $_SESSION array. Now let us assume that we really used our coding above – what values would we get ? Some integer numbers between 0 and 100 ?

The answer clearly is NO – we would always get “-1”. Why ?

You may say – maybe the connection is too fast and the $_SESSION variables may get erased when the upload has finalized. Well there is some truth in this also:

If we really wanted to test progress tracking in a LAN we may need to reduce the bandwidth of your network connection. Information about how one can achieve this can be found in the article
Geschwindigkeit/Übertragungsrate eines Netzwerkinterfaces unter Linux reduzieren

And yes – depending on the parameter setting in the “php.ini”-file the progress related elements of the $_SESSION array may get eliminated:

; Cleanup the progress information as soon as all POST data has been read
; (i.e. upload completed).
; Default Value: On
; Development Value: On
; Production Value: On
; http://php.net/session.upload-progress.cleanup
session.upload_progress.cleanup = On

But even if you reduced your bandwidth considerably in comparison to your transferred file you would nevertheless only get “-1” ! And even if you set the cleanup parameter to “Off” you would only get a trivial answer: 100.

The real reason for our failure is simply that the code execution of our PHP target program only starts when all data sent via the POST mechanism are completely received – this includes the file data!

This is very logical! The core purpose of the PHP job triggered by our file upload form in the last article is to deal with the uploaded file. It cannot be used for progress tracking by principle! We need a different and independent mechanism – in our case independent polling jobs.

So, when the PHP code listed above is executed on the server the file is already fully uploaded and the $_SESSION elements of $_SESSION which contained the progress information may no longer exist if the cleanup parameter is ON in php.ini settings!

The fact that the PHP job started by the upload form is of no use for progress tracking has two important implications:

First: By what should or could the PHP session for progress tracking be started at all in our Ajax controlled job environment? One assumption could be that the PHP engine does it by itself as soon as it somehow recognizes upload circumstances. However, this is not the case – and uncontrolled automatic session starts would actually introduce security risks into PHP. In fact we have reached an important point :

The PHP session must have been started already before our Ajax controlled file transmission from the client starts!

Otherwise the whole progress tracking process will not work! It uses a PHP session that must have been opened before!

How could we do this? Now, I may remind the kind reader about a note in the last article: Our HTML page with the upload form was created by a PHP program – which itself may use method of the classes of a template engine like Smarty. So, the PHP program that creates our initial web page already could open the required PHP session! An alternative would be that our client starts a precursor Ajax job with the sole purpose of opening a PHP session. Not very efficient, but possible.

And another aspect has become very clear now that would also be valid for independent polling jobs:

If we want to access the progress information in the $_SESSION array about the ongoing upload process we MUST have the $_
POST information about the upload process identifier available as the first information reaching the server – i.e. before the file data themselves start running in! This is the very reason why we had to take care about the order by which data are sent from the client to the server – see the related remarks in the previous article!

Note in addition that we did not destroy the session or unset its cookie at the end of our target program program function for Phase I. The reason is that we may use the session also in later phases.

Enough for today. Please, note also that the only substantial and effective things we have discussed so far on the PHP side were:

  • to access a hopefully already existing (!) PHP session,
  • to initiate the PHP output buffer

However, we have learned something about the key we use for accessing progress information in the $_SESSION array and understood its relation to a $_POST parameter, which must be provided by the client.

We shall come back to the treatment of the fully uploaded file by the methods listed above in a later article.
In the next article

CSV file upload with ZIP containers, jQuery, Ajax and PHP 5.4 progress tracking – IV

we shall instead look at the required sequence of Ajax controlled “polling” jobs started by the client to retrieve information about the upload progress status from the server. Independently of our main PHP job ….