windows driver development note # 4

วันนี้มาว่ากันที่ USB บ้าง ตัว device จะถูกเรียกว่า client และเครื่องคอมพิวเตอร์ของเราที่มี USB port จะเรียกว่า host
ตัว client มันก็จะรัน firmware สำหรับติดต่อพูดคุยกับ host และเพื่อบ่งบอกตัวเองว่าเป็นใคร (vendor id, product id, version id) ถูกคอนฟิกมาเพื่อติดต่อกับ host ในลักษณะใด โดยจะมีรูปแบบของคอนฟิกเป็นดังตัวอย่างข้างล่างนี้

configuration 1

• - interface 0
  
  • - endpoint (หรือเรียกว่า pipe) 0 ชนิด interrupt ทิศทาง IN (from device to host)
    - endpoint 1 ชนิด Bulk ทิศทาง OUT (from host to device)
    - ...
  - interface 1
  - ...

คอนฟิกอาจมีมากกว่าหนึ่งได้ แต่ active ใช้งานได้ทีละคอนฟิกเดียวเท่านั้น นอกจากนี้ device จะต้องมี default pipe เพื่อให้ host สามารถขอ descriptor ของ configuration ของ device นั้นๆ เมื่อเวลาที่มัน ถูก plug-in เข้าไป

packet คือ บล็อกของ data ทีส่งระหว่าง device กับ host ในหนึ่ง packet ประกอบด้วย synchronization signals, packet id (pid), data และ CRC check bytes

pid มี 10 ค่า แบ่งได้เป็น 4 ชนิด คือ

• token คือ OUT, IN , SETUP, SOF
  data คือ DATA0, DATA1
  handshake คือ ACK, NAK, STALL
  special คือ PRE
  

การทำ transaction ระหว่าง device กับ host นั้นจะเริ่มด้วย การส่ง token ตามด้วย data และ handshake ซึ่งจะมีทิศทางตรงกันช้ามกับการส่ง data

ชนิดของการ transfer หรือการทำ transaction นั้น มี 4 ชนิดด้วยกันคือ control, interrupt, bulk และ isochronous

ใน packet แบบ token นั้นจะมี address และ endpoint เพื่อบ่งชี้ device และ endpoint ที่ต้องการจะติดต่อด้วย

windows driver development note # 1

เป็นเพราะระบบดีไวซ์บนเมนบอร์ดนั้นเชื่อมต่อกันแบบต้นไม้หรือลูกโซ่ ดังนั้นระบบ driver หรือ software ที่ใช้ติดต่อกับดีไวซ์นั้นๆก็มีโครงสร้างเช่นเดียวกัน การทำงานตอบสนอง request จาก user mode ที่เป็น api เช่น read, write, open, close จะถูกเปลี่ยนมาเป็นรูปแบบของ message ที่วิ่งไปและกลับตามลำดับชั้นของ driver ใน kernel mode ที่เรียกว่า irp ซึ่ง irp จะประกอบไปด้วย header และ data structure ทีสัมพันธ์กับ driver แต่ละตัว เรียกว่า IO_STACK_LOCATION เมื่อ driver ทำงานก็จะทำการเปลี่ยนแปลงหรือเขียนข้อมูลลงในโครงสร้างข้อมูลที่ว่านี้

นอกจาก function driver ที่ติดต่อกับดีไวซ์จริงๆแล้ว ยังมี driver อีกชนิดหนึ่งชื่อ filter driver มันมีความสามารถในการเปลี่ยนแปลงแก้ไขข้อมูลที่ได้จากการทำงานของ function driver โดยการที่เรา install มันเอาไว้ใน chain ก่อนหรือหลัง function driver เพื่อประโยชน์บางอย่าง เช่น ทำการ encrypt ข้อมูลก่อนจะส่งกลับขึ้นไปให้ user mode

ขี้เกียจเขียนรูปอะ จะเอาของเขามาแปะ ก็กลัวโดนเรื่อง ลิขสิทธิ์อะ

มาสร้าง driver กันเหอะ

ความเดิมจากตอนที่แล้ว พอจะเริ่มเขียนตอนต่อไป ความขี้เกียจเข้าครอบงำทันที จึงเปลี่ยนวิธีการ น่าจะดีกว่า ตั้งธงเอาไว้ว่า อยากจะทำ driver อะไร แล้วค่อยๆทำไป step by step แล้วก็มาเล่าให้ฟังไปด้วย น่าจะเวอร์คกว่า

แต่ เอ ทำอะไรดีละ...

เอางี้ดีกว่า เรามาศึกษา USB driver กันดีกว่า ทำ hard lock เล่นๆดู โดยการใช้ flash drive ด้วยการ encrpyt ไฟล์ที่ใส่ serial number ไว้ แล้วให้โปรแกรมที่เราต้องการ protect อ่านออกมาตรวจสอบถ้า decrypt ได้ถูกต้องก็รันโปรแกรมต่อไป ถ้าไม่ถูกหรือหาไฟล์บน flash drive นั้นไม่เจอ ก็รันโปรแกรมไม่ได้

ท่าจะยาก เหมือนกันแฮะ เอาน่ะ ค่อยๆว่ากันไปทีละเรื่องละกันนะ

ATI - ตัดใจไม่ลง

อัพเดตล่าสุด กลับมาใช้ ati อีกแล้วอะ ด้วยความตะขดตะขวงใจ และตามประสาชอบมวยรอง ตอนนี้ fglrx รองรับ tvtime แล้วนะ มีคำสั่งที่สามารถมอนิเตอร์ดูคล็อก ดูอุณหภูมิของ GPU ได้ ก็ดีสำหรับงานภาคสนามนะ

ส่วนที่ไม่เข้าใจ และยังไม่รองรับ นั่นก็คือ pbo - pixel buffer object ก็ไม่รู้ว่าทำไมมันไม่ยอมทำสักที แต่ถึงกระนั้นก็เหอะ ข้อดีที่ทำให้ยอมรับมันได้กับการใช้ 4850 นะก็คือ กิน cpu น้อยลงมาก แถมการไม่ใช้ pbo ก็ให้ผลลัพธ์ที่ดี ยอมรับได้อีกด้วย อีกอย่างการรันโปรแกรมก็ไม่เกิดแครชเลย ทั้งทั้งที่บน nvidia นั้น 50-50 เลยแหละ

ไอ้ผมละเป็นงง

WDF Part 0

ห่างหายไปนาน มาคราวนี้ย้ายฝั่งกลับมา Windows บ้าง แต่จะกลับมาทั้งทีต้องมีอะไรเด็ดๆมาว่ากันยาวๆหน่อย น่าจะสนุกแน่ เพราะมีครบทั้ง hardware และ document มาให้ติดตามและทดลองกันให้เห็นจะจะ ไหนๆก็ซื้อมาดองไว้นานได้ที่และ

อันนี้เนี่ย เมื่อก่อนเนี้ยเป็นความใฝ่ฝันอันหนึ่งเลย แต่ด้วยเหตุว่ามันทำเงินให้ไม่ได้ และงานด้านนี้ก็โคตรหายากในเมืองไทย(ก็ต้องกิน ต้องใช้อะนะ) และจะศึกษามันก็ไม่ใช่เรื่องง่ายๆ ก็เลยพักไว้ก่อนแต่ก็ยังคงติดตามข่าวคราวอยู่สม่ำเสมอ เนื่องด้วยได้รับ magazine ชื่อ The NT insider อยู่เป็นประจำ(ฟรีอีกต่างหาก)มาหลายปีแล้ว ส่งตรงมาจาก OSR.com ก็ขอบคุณงามๆไว้ ณ ที่นี้ด้วย ในความกรุณา developer ไทยจนๆคนหนึ่ง กระทั่งทนหน้าด้านรับเค้าฟรีๆต่อไปไม่ไหว ก็เลยช่วยอุดหนุนโดยการซื้อ บอร์ดทดลองเพื่อการพัฒนาสิ่งที่กำลังจะพูดถึงต่อไปนี้

เกริ่นมาตั้งนานแล้ว บอกก็ได้ว่า สิ่งที่จะเขียนต่อไปในซีรี่ย์นี้ก็เรื่อง การพัฒนา driver ด้วย Windows Driver Foundation (WDF) ก็รู้อะนะว่าคงมีคนสนใจน้อยมากหรือไม่มีเลย แต่ถ้าไม่เขียนไว้ มันก็คงไม่มีต่อไป ก็หวังว่าสักวันมันคงทำให้ใครสักคนที่สนใจเริ่มต้นพัฒนาซอฟแวร์ชนิดนี้ได้ง่ายขึ้น ก็ถือเป็นการสืบทอดเจตนารมย์ของ OSR ต่อมาละกัน

เข้าเรื่องนิดหน่อยเลยดีกว่า พอเข้ายุค windows98, Windows2000 เรื่อยมาเนี่ย สถาปัตยกรรมของวินโดวส์ก็เปลี่ยนไปจากเดิมมาก การเขียนโปรแกรมเพื่อติดต่อกับอุปกรณ์ภายนอกนั้นต้องทำผ่านไดรเวอร์เป็นหลัก ดูง่ายๆเลยก็เช่น ปรินเตอร์ หรือ การ์ดจอ การ์ดเสียง หรืออุปกรณ์ที่ต่อภายนอกอื่นๆผ่านทางพอร์ตต่างๆ เข่น USB ก่อนใช้งานเราต้องลงไดรเวอร์ เพื่อให้วินโดวส์รู้จักเสียก่อนจึงจะสามารถใข้งานได้อย่างเต็มที่

ที่นี้ถ้าเราอยากสร้างดีไวซ์ขึ้นมาสักตัวหนึ่งเพื่อขายหรือใช้เองและต้องมีการติดต่อกับคอมพิวเตอร์เพื่อรับส่งคำสั่งและข้อมูลระหว่างกัน ทั้งสองฝั่งก็ต้องรู้จักกัน คุยกันรู้เรื่องได้ตลอดรอดฝั่ง มันก็ต้องมีวิธีการน่ะ ทางด้านตัววินโดวส์เองก็ต้องทำตัวเป็นตัวกลางเพื่อให้โปรแกรมที่เราใช้สามารถติดต่อสื่อสารไปถึงอุปกรณ์ที่ต่ออยู่ได้ ด้วยเหตุนี้เองการพัฒนาไดรเวอร์จึงเป็นสิ่งจำเป็นและดูเป็นศาตร์ด้านมืด(แปดด้าน) เนื่องจากต้องรู้การทำงานของเคอร์เนลของวินโดวส์และอาจจะต้องรู้การเขียนโปรแกรมบนอุปกรณ์นั้นควบคู่ไปด้วย ถ้าไม่มีใครช่วยทำให้อะนะ

เมื่อก่อนเคยพยายามศึกษามันหลายทีแล้ว แต่ไปไม่ถึงไหนสักทีด้วยเหตุผลที่บอกๆไปข้างต้น แต่มาบัดนี้ ด้วย WDF จะทำให้งานของเราง่ายขึ้น รึเปล่า? ก็ลองติดตามกันต่อๆไปละกัน วันนี้เมื่อยแล้ว พอแค่นี้ก่อน

ati ผิดหวังอย่างแรง

สืบเนื่องจากการทดลองลงเครื่อง pheonom + HD3870 ก็เลยซื้อมาทดลองใช้กับ project นี้ดูบ้าง ก็รากฏว่า ต้องผิดหวังอย่างแรง ตั้งแต่การลงที่ค่อนข้างยาก ผมลงไม่สำเร็จบน kubuntu 7.04 จึงต้องลงเครื่องใหม่เป็น 7.10 แล้วใช้ script จำพวก envy มาช่วยลงก็ถึงจะทำได้อย่างเรียบรอยดีไม่มีปัญหา

แต่ปัญหาหลักที่ทำให้ต้องยกเลิกความคิดที่จะใช้การ์ดนี้ก็คือ มันไม่สามารถเล่น tvtime ได้ เนื่องจาก fglrx ซึ่งเป็น driver ของการ์ด มันไม่ support pixel format YUY2 ซึ่ง tvtime ต้องการ

เซ็งเลย เพราะ performance เวลารัน glxgears เมื่อเทียบกับ 8600gt นั้น มันทำ frame rate ได้ดีกว่าถึง 2 เท่า เดี๋ยวจะไปซื้อ 9600 มาลองเปรียบเทียบกันอีกที

OpenGL ตอนที่ 2

ในที่สุดก็ใช้งาน OpenGL เบื้องต้นได้ ที่บอกว่าเบื้องต้นก็เพราะ มันดูเหมือนไม่ได้ช่วยให้ CPU ทำงานน้อยลงเลย หรือมันถูก block ไว้ก็ไม่รู้ แต่มันก็ช่วยให้ frame rate ดีขึ้นแหละนะ หลักๆที่แก้ไป ไม่ใช่เรื่อง multi-thread เพราะออกแบบให้ copy ลง memory ก่อนแล้วค่อยให้ gui thread เรียก glTexSubImage2D อยู่แล้ว แต่เป็นเรื่องการทำงานร่วมกันระหว่าง wxGLCanvas กับ glut และ OpenGL มากกว่า โดยไปออกแบบใหม่ให้ลด layer ของ window ลง ลองไปอ่านใน wiki ดูนะคร้าบ อีกอันหนึ่งคือ การสร้าง texture object ดูเหมือนว่าเราจะสร้างใน constructor ของ wxGLCanvas ไม่ได้นะ ต้องให้มัน show ก่อน

อย่างไรก็ดี คงจะต้องปรับปรุงกันต่อไป เห็นมีการพูดถึง Pixel Buffer Object ไม่รู้ว่าจะช่วยได้ป่าว ต้องลองดูตามที่ไปหามา(อีกแล้ว)

1. Create PBO
2. map buffer
3. give pbo pointer to decoder thread (or put it in pool of free pbo's)
4. decoder copy frame in pbo memory and notify render thread about that, or decoder ask pool for free pbo pointer and copy image data and notify render thread about that.
5. render thread unmap pointer and call glTexSubImage2D
6. render thread mark that pbo to map its pointer again at next frame (or two frames later)
7. at next frame (or two frames later) map pbo pointer and give it to decoder thread (or pool)

Using pool you can handle multiple video stream transfers.

ก๊อปมาจาก ที่นี่ จ้า

ติตตามความคืบหน้ากันต่อไป

OpenGL and Multithreading

หลังจากที่ต้องการวาดภาพที่ได้จากหลายๆตัวพร้อมๆกัน โดยใช้ multi-thread นั้นก็พบว่า ถ้าไม่ใช้ความสามารถของการ์ดจอเข้ามาช่วยละก็พอแต่ละ window มันใหญ่ขึ้น ก็จะกิน cpu แบบมหาศาล แล้วจะ crash ไปในที่สุด ไม่สามารถรันติดต่อกันเป็นเวลานานๆได้ นั่นเป็นเรื่องที่ยอมรับไม่ได้เลยทีเดียว (จากการทดสอบ ถา้เปิดแค่สองกล้อง จะรันได้ข้ามวัน แต่ถ้าเปิดสี่กล้อง สองชั่วโมงก็ตายแว้วว) อันนี้ไม่เกี่ยวกับเมมโมรี่ แต่สังเกตได้ว่าเกิดจากการที่ main thread ซึ่งทำหน้าที่วาดที่ทุกอย่างนั้นทำงานช้าเกินไป

จากที่เล่ามาข้างบนจึงมาคิดว่า คงต้องให้การ์ดจออันแสนแพง ทำงานคุ้มค่าหน่อย วิธีหนึ่งที่ทำได้ง่ายๆคือใช้ OpenGL ใช่มั้ยครับ แต่ แต่ช้าแต่ ช้าก่อนครับ มันไม่ง่ายอย่างนั้นน่ะสิ เพราะตอนนี้เราทำงานแบบ multihreading ซึ่งตัว OpenGL มันเหมือนจะไม่ได้ออกแบบมาเพื่อการนี้สักเท่าไร ถึงกระนัน้ก็ตาม ไม่ใช่ผมเป็นคนแรกที่คิดจะทำแบบนี้แน่่นอน ว่าแล้วก็ค้นดูจาก google จนได้ link ไปที่ forum ซึ่งมีการพูดคุยเรื่องนี้อยู่ และมีคนแนะนำไว้ว่าอย่างนี้

(I copied this below text from this link)
The basic problem with multithreading in OGL is the fact that OGL context, which contains entire state of the OGL, can be at one time bound to only one thread. Because of this you can not simultaneously modify it from two threads. You basically have three options.

• You can create one context for each thread and enable sharing of display lists and textures between them. It is likely that this path is not too well supported by the drivers.
• You can load and prepare the resources by the second thread and let the main thread do the creation call into OGL.
• If the resource type supports it (e.g. VBO), you can map its memory by the main thread. Fill it in the second thread and unmap it by the main thread

ประเด็นมันอยู่ตรงนี้เอง นั่งทำอยู่สองวัน ได้แค่หน้าจอดำๆ ต้องกลับไปแก้ไขใหม่ ได้เรื่องอย่างไรแล้วจะเอามาให้ชมเป็นตอนต่อไป อ้อ การเขียน OpenGL บน wxWidgets นั้น เค้ามี class wxGLCanvas่ กับ wxGLContext มาให้ใช้ ช่วยให้สะดวกขึ้นมิใช่น้อย

wxWidgets part: wxThread

หลังจากที่สร้้างฟอร์มเสร็จอย่่างสวยงามได้ดังใจมาแล้ว ก็ถึงคราวใส่อะไรๆลงไป รูปข้างบนผมได้เขียนโค้ดการรับภาพจากกล้อง cctv ซึ่งต่อกับการ์้ด DVR แบบ real-time 4 channel โดยใช้ API คือ Video For Linux 2 และใช้ OpenCV library ช่วยในการจัดการภาพในขั้นตอนต่อๆไป พอดีว่ามีสายอยู่สามเส้นจึงทดลองต่อกล้องได้สามตัว

wxWidgets ทำให้ผมประทับใจอีกครั้ง ด้้วยการสนับสนุนการเขียน multi-thread และคำนึงถึงการติดต่่อระหว่าง worker thread และ main thread ซึ่งปรกติจะรัน GUI ทำให้ออกแบบโปรแกรมและเขียนโค้ดได้ง่ายขึ้น

อย่างที่ผมทำนั้น ได้ใช้วิธีการสร้าง worker thread ซึ่งจะทำหน้้าที่ติดต่่อกับกล้อง 1 thread ต่อ 1 ตัวแล้วก็ส่งภาพมาให้ window object แต่ละช่องทำการวาด

จากเอกสารและตัวอย่างนั้นได้แนะนำเอาไว้ว่า

1. ไม่ควรมีการเรียก GUI function จาก thread เกินกว่า 1 thread
2. ถ้าต้องการทำ ให้ใช้วิธี post event แทนซึ่ง function ที่สนับสนุนนั้นเป็น thread safe จึงไม่ต้องกังวล
3. อีก 2 ฟังก์ชั่นที่สำคัญคือ wxMutexGuiEnter และ wxMutexGuiLeave

wxFormBuilder part: 3

หลังจากที่ design กันไปแล้้ว ก็เอามาคอมไพล์ในโปรเจ็กที่สร้างบน KDevelop ที่เห็นเป็น 4 ่ช่องนั้น แต่ละช่องเป็น custom window object ที่พร้อมสำหรับการวาดภาพลงไป ว้าวๆ ประทับใจจริงๆ

wxFormBuilder part: 2

หลังจากที่ทดลองใช้กันอยู่วันหนึ่งเต็มๆ ก็ต้องบอกว่าค่อนข้างประทับใจมาก ด้วยเหตุผลหลายๆประการ ดังนี้
1. ตัว tool ใช้ง่าย แต่ต้องทำความเข้าใจคอนเซ็ปต์ของมันให้ได้เสียก่อน เมื่อทำความคุ้นเคยได้แล้ว ทีนี้ก็ออกแบบได้ง่าย
2. ตัว code ที่ generate ออกมาเป็น OO ใครที่คุ้นเคยกับการเขียน win32 api ละก็ จะรู้สึกได้ว่ามีส่วนคล้ายกันอยู่มากทีเดียว ทำให้เดาทางได้ง่ายขึ้น
3. อันนี้อ่านมาจากใน forum เค้าว่่าด้วยการทำแบบนี้ คือ แยก gui code ออกจาก logic ทำให้ออกแบบ automate test ของส่วน gui ได้ง่าย
4. มีตัวอย่างการใช้ร่วมกับ OpenCV และ openGL ซะด้วย
5. support multi-threading

ที่เหลือก็เรื่องความเสถียรกับประสิทธิภาพ ก็ต้องลองดูกันต่อไป

GUI toolkit : WxFormBuilder

วันนี้กะว่าจะยกเครื่อง GUI ของโปรแกรม traffic monitor ซึ่งตอนนี้เขียนด้วย FLTK 1.1 แบบง่ายๆไว้ เนื่องด้วยความต้องการที่จะทำให้มันดู professional ขึ้นมา กับคนที่เกลียดการเขียน UI ที่สุดมันจะกลายเป็นเรื่องยุ่งยากใจทันที สิ่งที่ไม่ชอบที่สุดของ FLTK ก็คือ ui designer tool ที่เข้าขั้น ห่วย ไม่ว่าจะเป็นหน้าตาหรือการใช้งาน ฟังดูอาจขัดกับที่เคยแนะนำไป แต่ช่วยไม่ได้อะ พอต้องการที่จะทำให้มันสวยๆ มันรู้สึกอย่างนั้นจริงๆ

วันนี้ก็เลยเสียเวลาทั้งวันในการหา toolkit ตัวใหม่ที่ต้องการจะลงหลักปักฐานด้วยไปตลอดต่อจากนี้ ตอนแรกลังเลว่าจะกลับไปมอง QT/KDE แต่มานึกถึงเรื่อง license แล้วก็เลยไม่อยากเสี่ยง มองหาที่เป็น GPL/LGPL ดีกว่า ด้วยความที่มันเป็น opensource ข้อเสียอย่างหนึ่งก็คือ มันมีให้เลือกเยอะจริงๆ ก็ต้องมานั่งหา นั่งเปรียบเทียบ ลองลงอยู่กันเป็นนานสองนาน การตัดสินใจเลือกตัวใดนั้นจะมีปัจจัยหลักสองข้อคือสนับสนุน OpenGL และ multi-thread

ตอนแรกเลยก็ลอง FLTK 2.0 ซึ่งเวอร์ชั่นนี้บอกว่าเป็น OO มากขึ้น แต่ก็ยังไม่ประทับใจเท่าไร สุดท้ายก็มาจบที่ wxWindows ซึ่งก็ดันมี tool มาเป็นตัวเลือกสำหรับทำ rad หลายตัวอีก ท้ายสุดเมื่อเปรียบเทียบจากตาราง ก็เลยตกลงปลงใจกับ wxFormBuilder v3.0 เวอร์ชั่นนี้ต้องการ wxWidget version 2.8

เนื่องจาก Kubuntu ที่ใช้อยู่เป็น version 7.04 จึงต้องทำการ upgrade wxWidget เสียก่อน เอาละตอนนี้ก็พร้อมที่จะทดลองใช้มันแล้ว ขอเวลาไปลองเล่นก่อน ได้ผลยังงัย ชอบ ไม่ชอบ จะมาบอกอีกที

Kubuntu on Amd64 Phenom

ในที่สุดก็ลงสำเร็จจนได้กับเครื่องใหม่ของทีมที่เป็น Phenom 9500 + HD3870 ปัญหาก็มีหลายอย่างเหลือเกิ๊น ตั้งแต่ write iso image ด้วยโปรแกรมบน Kubuntu แล้วเอามาลงไม่สำเร็จ สุดท้ายจำเลยก็คือ(คิดว่านะ) ตัว writer ที่บ้านนั่นเอง เป็นยี่ห้อ LiteOn แต่เครื่องใหม่เป็น Asus พอเอาไปเขียนด้วยเครื่องที่ทำงาน ซึ่งเป็น Asus เหมือนกัน ก็จบข่าวเลย

ต่อมาก็เรื่องลง driver ของ ATI เทียบกับลง driver ของ Nvidia เจ้าหลังนี่ไม่ค่อยมีปัญหาเท่าไร แต่ข้อดีของ ATI คือจะมีโปรแกรม config มาให้ชื่อ Catalyst ใช้ set feature ต่างๆได้สะดวกดี

ปัญหาต่อมาก็คือไม่สามารถเซ็ตความละเอียดที่ 1680x1050 ได้แม้ว่าจะเข้าไปแก้ xorg.conf ตรงๆ ทางแก้ก็คือ ต้องใช้คำสั่งหรือโปรแกรมที่ทำการ reconfig X-server ใหม่ ถึงจะได้

หลังจากนั้นก็ฉลุย ลง Apache2, trac, svn แต่ยังไม่ได้เซ็ตเลยอะ รำคาญเสียงพัดลมของเคสมาก ทนไม่ไหวซะก่อน นี่ว่าจะแกะออกมาถอดสายไฟออกซะเลย ไม่น่าจะเป็นไรมั้งเนอะ เห็นว่า cpu ตัวนี้ไม่ร้อนเท่าไรแถมเคสก็ใหญ่มีพื้นที่มากอยู๋แล้วด้วย

Render farm

เมื่อวานสมัครสมาชิก LinuxJournal ไปปีหนึ่งบวกกับ online access เล่มใหม่เขียนถึงหนังเรื่อง Spiderwick Chronicles ว่าสตูดิโอที่ทำกราฟิกให้นั้นใช้ Linux เกือบทั้งหมด ทั้งออกแบบโปรแกรมขึ้นมาใหม่และ render farm ทำให้ต้องเก็บไว้ในความอยากส่วนตัวอีกอันหนึ่งว่า อยากจะทำสตูดิโอที่ให้บริการ render ด้วย Linux farm บ้างจัง นอกเหนือไปจากที่เคยอยากทำ video wall ด้วย Linux

ตังค์จ๋า อยู่ที่ไหนหนอ?

FLTK gui programming

เดี๋ยวนี้ ภาษาสคริปต์มาแรงมาก ทุกอย่างที่เคยเขียนด้วย c++ ก็เอามาเขียนด้วยสคริปต์ได้แล้ว ดูตัวอย่างได้จาก Python ส่วนตัวเป็นคนที่ไม่ชอบภาษาสคริปต์ เพราะเป็นคนไม่มีระเบียบเท่าไรอยู่แล้ว เจอภาษาที่มันยืดหยุ่นได้มากๆนี่ จะงงเอา อีกอย่างรู้สึกแก่เกินจะเรียนรู้อะไรแบบนี้แล้ว ก็เลยมองหาอะไรที่ friendly กับสิ่งที่เราเป็นอยู่ดีกว่า
เมื่อต้องทำ application และมี gui ด้วยซึ่งเป็นอีกเรื่องที่ไม่ชอบเอาซะเลย ก็เลยมองหาตัวช่วย ก็ไปเจอเข้ากับอะไรที่คิดว่าเหมาะกับตัวเรามากทีเดียว นั่นคือ FLTK นี่เอง มันดียังงัยเหรอ มันก็คล้ายๆ เราใช้ visual sutdio และออกแบบ gui บนนั้นน่ะแหละ มันจะมี tool สำหรับ ออกแบบ แล้วสามารถ convert เป็น c++ code ให้เราใช้ได้เลย ก็ลดความน่าเบื่อลงไปได้มากทีเดียวนะ
สนใจก็ลองไปเล่นกันดู

Step 1: Video for Linux API

การทำ application ด้าน realtime video processing ไม่ว่าจะ apply ไปใช้ด้านไหน เช่น broadcasting, editing, computer vision, image processing สิ่งสำคัญอันดับแรกนั่นก็คือ การรับ data input เข้ามานั่นเอง ยิ่งเป็นด้านที่เกี่ยวกับ streaming ด้วยละก็ เน้นเลย เพราะต้องรับ data เข้ามาอย่างต่อเนื่อง ดังนั้นเรื่องความถูกต้อง, frame rate, คุณภาพ และความเสถียร ของระบบจึงเป็นเรื่องสำคัญมากๆ

การเขียนโปรแกรมติดต่อกับ video input บนลินุกส์นั้นอาศัย API ที่ชื่อว่า Video For Linux (v4l) ซึ่ง driver เกือบทุกตัว สนับสนุนการติดต่อผ่าน v4l นี้ทำให้ไม่ต้องคำนึงว่า hardware จะเป็นอะไร หมายความว่าถ้าเราสามารถ setup (install driver, config)ให้อุปกรณ์ทำงานได้แล้วละก็ โปรแกรมที่เราเขียนด้วย v4l สามารถคุยกับอุปกรณ์นั้นได้อย่างแน่นอน เช่น webcam USB, dvr card

ปัจจุบัน v4l มี 2 เวอร์ชันซึ่ง ซึ่งแนวทางการเขียนก็ไม่ได้แตกต่างกัน คือ เรียกใช้ฟังก์ชันต่างๆผ่านทาง ioctl() ซึ่งมีทั้ง get และ set คุณสมบัติต่างๆของตัวอุปกรณ์

วิธีที่ดูจะง่ายและเสถียรที่สุดในการรับภาพเข้ามาคือ รับแบบ blocking function โดยใช้ mmap เพราะเราจะได้ framerate ตามความเป็นจริงเลย โดยไม่ต้องมานั่ง sync เอาเอง แต่สิ่งที่ต้องคำนึงก็คือจำนวน buffer ที่จะใช้เอาไปรับภาพหรือข้อมูลมา ที่เคยลองเขียนมาอย่างน้อยต้องเป็น double buffer จึงจะได้ภาพที่ full framerate จริงๆ เช่น ถ้าเป็น PAL ก็จะเป็นที่ 25 fps

เมื่อมีระบบที่ให้ raw data ที่ดีได้แล้ว จะทำไรต่อไปก็เชิญตามสะดวกได้แล้วทีนี้

ถ้ามีใครเข้ามาทัก จะเขียนต่อ (coding by example) อิอิ