[Gelistirici] [Uludag-commits] r14504 - trunk/staj-projeleri/zorg/zorg

[Onur Küçük]

> Randr ile illa X açmak gerekip gerekmediğini bilmiyorum, ama zaten probe
> ederken X açmak zorunda kalmıyor muyuz, en azından mevcut durumumuz böyle?

 Her bilgi probe edişimizde bir daha X açmamız gerekiyor. Örneğin driver ın ne 
olduğunu bulmaya çalışırken bütün sürücüler denendiği için oradan güvenilir 
monitor bilgisi alamayız. Her işlem için biraz daha bilgi ekleyip öyle probe 
ettirmek gerekiyor ki bunun için X açmak şimdilik "bazen mecbur kaldığımız 
bir overkill".

> > Bir de her sürücü EDID
> > bilgisini alamıyor. Mesela, (en son durumunu bilmiyorum ama) nv
> > sürücüsünün DVI girişine takılı monitörü algılayamaması gibi bir durumla
> > karşılaşmıştım.
>
> nv sürücüsüne randr branchını yeni merge edildi, ati/radeon serisi yolda :)
>
> > Zaten log incelemekten başka sürücülerden bilgi almanın bir
> > yolu da yok sanırım. Yine EISA ID sini kullanarak monitör veritabanından
> > ve windows sürücülerinden faydalanma şansımız var.
> >
> > Yeni randr'nin neler yapabildiğine bakmadım. randr ile yapabileceklerimiz
> > de yine xorg.conf dosyasındaki bilgilere bağlı diye biliyorum.
>
> Yeni randr serisinin ulvi amacı xorg.conf denilen naneyi ortadan kaldırmak
> ya o yüzden şu an durum tam tersi olmalı :) (configde yapabileceklerin
> randr ile sınırlı)

 Randr daha uzun süre xorg.conf olmadan kendi başına bir şey yapamayacak. 
Randr nin içinde şu anda donanım tanıma ile ilgi bir şey de yok, tasarım 
olarak da girmemesi lazım.

xorg-server-1.3.0.0 $ LC_ALL=C grep -ri EDID randr/*
xorg-server-1.3.0.0 $ LC_ALL=C grep -ri vesa randr/*
randr/Makefile:KDRIVEVESA_FALSE =
randr/Makefile:KDRIVEVESA_TRUE = #
randr/Makefile.in:KDRIVEVESA_FALSE = @KDRIVEVESA_FALSE@
randr/Makefile.in:KDRIVEVESA_TRUE = @KDRIVEVESA_TRUE@
xorg-server-1.3.0.0 $ LC_ALL=C grep -ri EISA randr/*
xorg-server-1.3.0.0 $  


libXrandr-1.2.1 $ LC_ALL=C grep -ri EISA *
libXrandr-1.2.1 $ LC_ALL=C grep -ri VESA *
ChangeLog:      * Xrandr.c, Xrandr.h: Add initial RandR support to Xvesa
libXrandr-1.2.1 $ LC_ALL=C grep -ri EDID *
libXrandr-1.2.1 $        


 Bu işi sürücülerin yapması ve X e iletmesi gerekiyor ki hiç bir sürücüde şu 
anda ortak bir config arabirimine yönelik bir şey yok. Şu anda en fazla 
libxf86config den veri okuyup kullanıyorlar ama onda da ortak bir şey yok, 
bildiğin string parsing yapıyorlar. Bazı sürücüler DefaultDepth e bakıyor, 
bazıları bakmıyor gibi saçmalıklar var orda.


> Aslında derdim neden biz yapıyoruzdan öte ortada zaten bunu yapmaya çalışan
> birileri var, bu birileri aynı zamanda bunu yapmaya çalıştığımız platformun
> da geliştiricileri hani hal böyle olunca olanı kullanıp onun sorunlarını
> çözmek, kendimiz yazıp kendi sorunlarımızı çözmekten daha efektif olacakmış
> gibi geliyor, hani bu paket yöneticisi değil ki dizaynı yanlış diyelim :P

 Keşke dediğin gibi olsa ama X bu işi becerebiliyor olsaydı zorg diye bir 
aracımız olmazdı. Hala ortak bir altyapı yok, hala herkes (sürücüler libler) 
kendi bildiğini okuyor, hala config olmadan çalıştırınca düzgün çalışma şansı 
çok düşük.

 Xorg un bu sorunu yakın zamanda çözebileceğini de zannetmiyorum. Zaten 
tasarımında böyle bir şey yok. Çözdükleri zaman atalım gitsin ne varsa, ama 
oraya daha çok var.

 Bu arada Fatih ddc kısmını baştan yazmıyor, ddcxinfos u ayıklıyor ve python 
modülü haline getiriyor. Böylece komut satırından çağırıp çıktıyı ayrıştırmak 
yerine istediğimiz yerden pythonla çağırıp kullanabileceğiz.

-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens