Re: [ANNOUNCE] xf86-input-fpit 1.4.0
Thanx for maintaining the driver. AFAIK kernel input driver does not exist, and this is one of last resort to make one enjoy wonders of X. ad. testing - i still use much older version , which works fine, except pointer goes crazy under heavy load sometimes. it seems that it's serial port is polled, and machines have issues with acpi timer sources, which in combination makes bit of disaster. either way it's useable on fujitsu stylistic 2300 i happen to own. btw. recently i've thought of standarising such old devices by hardware hacking , i.e. to insert 'standariser' device inbetween computer and problem device like some once-released-never-maintained tablet, mouse, etc. such device would be simple transcoding microcontroller. ofc. for devices like tablets or laptops this is still not really applicable, as it's difficult to hack something like this inside... one of problems with such thing though is that there are not really 'standard' devices , i.e. each of them is related to some vendor , and any of them is not de facto 'standard'. greetings and thanx for good work -- On Mon, 27 Jun 2011, Peter Hutterer wrote: This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. 1.4.0 has actually seen testing in the form of loading the module, enjoying a view of a non-crashing X server (-retro too, I'm soo 80s today...) and thus deducting that the driver is bug-free. Which is more testing than previous releases have seen. Nonetheless, you may not want to control your nuclear power plants with this driver. Alan Coopersmith (1): Fill in COPYING file, add SubmittingPatches URL to README Peter Hutterer (19): Cope with XINPUT ABI 7. Fix module unloading. Remove unused bits from configure.ac Bump to 1.3.99 Purge CVS tags Remove refcount field, dropped from the server unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr. Drop close_proc, conversion_proc, reverse_conversion_proc Drop libc wrappers for free, malloc Require server 1.9, drop earlier ABI support Use GetMotionHistorySize() instead of driver-internal history Support input ABI 12 Bump minimum required server version to 1.10 Include xorg-server.h, not xorgVersion.h Reshuffle configure.ac to be more in-line with other modules Remove usage of sdkdir - not used by this driver Add 50-fpit.conf default configuration file. fpit 1.4.0 philip (1): fpit: minX/ maxX get wrongly initialized git tag: xf86-input-fpit-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.bz2 MD5: 042c95fec145d8b57ca62714131ff3f1 xf86-input-fpit-1.4.0.tar.bz2 SHA1: 9305d30ae22d37c6b5bb975adc8ecda9b1d6c5e6 xf86-input-fpit-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.gz MD5: 1f262074106c855b090295faadaedb80 xf86-input-fpit-1.4.0.tar.gz SHA1: 58c3b2f8306e5f2fa69a7636e2d74a88ca24e703 xf86-input-fpit-1.4.0.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? personally i doubt it, thus i doubt it makes any point to try to put it to vanilla. also there are other devices like tablets (like the wacom stuff), joysticks, touchpads etc. which are cursed with similiar problem - they appear as 'mere' serial device, they 'just' stream the data, yet each of them speaks bit different language. and then - they all seem to do quite same thing... xyz/buttons... ...except perhaps some 'universal' driver could be created, which would have option to transcode inbetween various input devices like those internally... so 'desperate users' could just tinker with translation rules , rather than having to modify driver itself (even though it might seem so simple...) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? hmm, as i've googled a bit for pentest.c i've realized phasing driver to linux kernel drops support for such devices for i.e NetBSD users... and it seems some users of such are in fact preferring those over linux... esp. linux gets bigger and bigger nowadays... not to mention i recall i had loads of trouble making never kernel versions work on stylistic - over 2.6.31 problems with kacpid consuming 99% cpu and hibernation started to appear, and i somehow gave up trying to investigate why after certain point... so again, some kind of user-space solution is imho better, esp. it's 'hardware' is in fact mere serial port, already supported by most OS's. btw. thanx again for updating current fpit driver :) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.10.0
On Sun, 27 Feb 2011, Matt Turner wrote: On Sat, Feb 26, 2011 at 5:20 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: On Sat, 26 Feb 2011, Alan Coopersmith wrote: On 02/26/11 01:20 AM, Piotr Gluszenia Slawinski wrote: xfree86: Drop linux libc5 support from the SIGIO code hmm, could this be elaborated? affects older slackware boxes, etc. Those summaries all come from git, so to get more details, simply look at the commit in git: http://cgit.freedesktop.org/xorg/xserver/commit/?id=47c91dca8d8eecb429123e8370302831bcd57938 thanx. personally i do not think this code breaks anything for normal users, it does not introduce bloat - it's ifdef, so why remove it? even if 'defunct', it's at least in correct place. What could possibly be correct about running libc5 in 2011? If you want to run libc5 or Linux 1.2, fine, but an equivalently ancient version of xfree86 should go along with it. it is very strange policy. i can understand investiment in bugfixes can be dropped, but removal of code which does not do any harm , just to FORCE 'libc incorrect' people to use old Xfree or upgrade is IMHO not right. concerning such code - perhaps adding another #ifdef, depending on i.e. ENABLE_ANCIENT_AND_UNTESTED variable around such code could be some compromise, instead of just removal. p.s. FIY libc5 is used not only with linux. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.10.0
xfree86: Drop linux libc5 support from the SIGIO code hmm, could this be elaborated? affects older slackware boxes, etc. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.10.0
On Sat, 26 Feb 2011, Alan Coopersmith wrote: On 02/26/11 01:20 AM, Piotr Gluszenia Slawinski wrote: xfree86: Drop linux libc5 support from the SIGIO code hmm, could this be elaborated? affects older slackware boxes, etc. Those summaries all come from git, so to get more details, simply look at the commit in git: http://cgit.freedesktop.org/xorg/xserver/commit/?id=47c91dca8d8eecb429123e8370302831bcd57938 thanx. personally i do not think this code breaks anything for normal users, it does not introduce bloat - it's ifdef, so why remove it? even if 'defunct', it's at least in correct place. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Documentation
Nima Sahraneshin unix.n...@gmail.com writes: Hi I want to write a program based on X .I need some documentation about X (using X) . Assuming that you want to make an ordinary application that is going to run under X, you really want to use a toolkit. These days, Qt (http://qt.nokia.com/) and Gtk (http://www.gtk.org/) are probably the best alternatives. They are much easier to work with than coding directly for X, and they do a lot of things for you that is otherwise a royal pain to get right. they both have serious shortcomings, and bugs, which make target application either non-functional after routine API changes (nokia) or bloated, buggy and slow (gtk). coding either directly for X or using lighter toolkits (i.e. fltk) has some point, and saves royal withdrawal after royal painkillers. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Documentation
On Mon, 3 Jan 2011, Alan Coopersmith wrote: On 01/ 3/11 09:28 AM, Piotr Gluszenia Slawinski wrote: coding either directly for X or using lighter toolkits (i.e. fltk) has some point, and saves royal withdrawal after royal painkillers. ...and saves you from having to deal with users who need the accessibility or internationalization support the toolkits provide you. After all, who needs users who don't have exactly your needs? If toolkits were useless, they wouldn't be used for almost all serious applications. i am not claiming toolkits are useless, was more adressing statements like you really want (for simple app - not really) and qt and gtk are best choice (quite bold, almost advertisement-like claim. either way - one indeed can make it easy and there is wide choice of toolkits, out of which many are even cross-platform : http://en.wikipedia.org/wiki/List_of_widget_toolkits#Cross-platform or one can code directly, when app is simple/disposable enough , and adding toolkit would be just a waste of resources (i.e. like vncviewer, mplayer, etc.) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
neomagic and 1.8.2
just noticed that neomagic got broken with 1.8.2 console switching no longer works, and sporadically X crashes when typing text in console using keyboard (though this might be problem of X itself. ) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
fpit and max X position for calibration
I've upgraded to xorg 1.8.2 and 1.2.4 fpit driver recently, and it works, except it's X position is uncalibrated, and driver seems to ignore settings passed to it in xorg.conf. Xorg.log seems to show that those values are recognized, but they are effectively ignored (no matter what one puts there, it's still same) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: fpit and max X position for calibration
On Fri, 13 Aug 2010, Piotr Gluszenia Slawinski wrote: I've upgraded to xorg 1.8.2 and 1.2.4 fpit driver recently, and 1.3.0-r1 obviously :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: fpit and max X position for calibration
I've upgraded to xorg 1.8.2 and 1.2.4 fpit driver recently, and 1.3.0-r1 obviously :) http://www.mail-archive.com/ubuntu-x-s...@lists.launchpad.net/msg69863.html just for reference and 'notepad' - seems someone else already got affected by this bug... problem is bit annoying as it's hard to use 'older' versions of drivers, and they will be removed from i.e. gentoo's portage tree soon as it happens with other older x releases... -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: fpit and max X position for calibration
On Fri, 13 Aug 2010, Piotr Gluszenia Slawinski wrote: I've upgraded to xorg 1.8.2 and 1.2.4 fpit driver recently, and 1.3.0-r1 obviously :) http://www.mail-archive.com/ubuntu-x-s...@lists.launchpad.net/msg69863.html just for reference and 'notepad' - seems someone else already got affected by this bug... problem is bit annoying as it's hard to use 'older' versions of drivers, and they will be removed from i.e. gentoo's portage tree soon as it happens with other older x releases... https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/+files/xserver-xorg-input-fpit_1%3A1.3.0%2Bgit20100504.a7e1d84c-0ubuntu0sarvatt_1%3A1.3.0%2Bgit20100519.2d6975f8-0ubuntu0sarvatt%7Elucid.diff.gz fix. seems typo in previous fix. so fix the fix! i will test asap, but looks obviously right. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X lib support for embedded systems.
Twas brillig at 06:49:01 11.08.2010 UTC+02 when curi...@bwv190.internetdsl.tpnet.pl did gyre and gimble: PGS i also recall long gone times when i could build 3.3.6 XFree which PGS would run on 486 with 8M of ram , and squash the (static!) binary PGS to just 2M. perhaps with uclibc this could be even smaller. PGS main problem those times are long gone :/ numbers like 20M start PGS to appear, and Xorg is not really optimised for embedded devices PGS performance-wise. Those are sentiments. Do you have hard facts to prove your point? what facts do you need ? try tools like qpkg, ls -lha and calculator on your own systems. also try to run Xorg on anything with 32/64M ram and see how much memory it consumes. sure it does work. i suceeded compiling google chrome for 64M machine not so far ago. it even started and displayed page. the actual time it took is what makes difference ;) i've seen neat embedded systems with ~266mhz arm cpu's able to rotate simple 3d objects, zoom in/out, scroll and pan with frame rates close to 50fps, and memory footprint under 32M. unfortunatelly Xorg and linux still has long way to reach such performance, and those are hard facts, which cannot be torn down 'but those are simplified apps not supporting whole X protocol' - they are fit for purpose, and sometimes one doesn't need cannon to shoot squirrel... -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X lib support for embedded systems.
On Wed, 11 Aug 2010, Mikhail Gusarov wrote: Twas brillig at 08:13:29 11.08.2010 UTC+02 when curi...@bwv190.internetdsl.tpnet.pl did gyre and gimble: PGS what facts do you need ? try tools like qpkg, ls -lha and PGS calculator on your own systems. Desktop X.org? Are you joking? is there any other? PGS also try to run Xorg on anything with 32/64M ram PGS and see how much memory it consumes. Well, I do every day. Works pretty much fine. well, it all depends what u call 'fine' if it's 'managed to boot up, took half of memory and runs @ 5fps' then sure ;) btw quick mem check on one of my uclibc based machines : top memory consuming app: Xorg 45M resident (!) , 329M virtual. apps opened - xchat, few windows with links browser, few terminal windows, xastir . wm - fluxbox. i also do run X on 64 and even 32M machines, mainly because X is just easy to deploy and some apps i use are not yet ported to directfb. mem stats are quite similiar, top mem usage app - X. performance ... well. above 1fps. it can be considered 'it works', right ? ;) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
RE: X lib support for embedded systems.
Ok its like this: Our application was developed using fltk-1.3.x. We have lots of existing code that depends on fltk. But the person who decided to use fltk-1.3 was really a moron. Because, fltk-1.3 was modified by nano-X people to use nxlib interfaces, and all to test the nano-X (x server type) library. This was a few years back. Now we need a change in fltk. fltk-1.3 has latin1 encoding support and we need our application to internationalize. Now for the same we have an answer with fltk-2.0. It supports utf-8. Also note that all of the fltk is built and tested with X11. The problem is if I use the same setup, replace fltk-1.3 with fltk-2.0, I need to do lots of changes in nxlib and nano-X, for which I do not have enough time and also it is risky. So I think that the easiest solution would be have X11 running on the system directly. So that fltk-2.0 runs without any problem. Do you follow? which architecture and video you are using? there are few distros optimised for size, if you want something ready, or you can just use i.e. gentoo to build packages, and then copy those packages to your embedded system image manually, or using simple script utilising dependency list dump... you can get few megabytes extra by compiling everything against uclibc, but you have to either make sure to use nptl branch of uclibc (and have your arch supported) or make sure just linux threads are used by your apps (no nptl). you can get few extra hundreds of kb by using either upx on binaries , or even over 50% size reduction by using i.e. squashfs to compress library dirs, binaries, and all other read-only stuff. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
RE: X lib support for embedded systems.
On Wed, 11 Aug 2010, Praveen J C (RBEI/EST1) wrote: OOPS.. I forgot to mention that i must be using linux OS. Also I came across kdrive.. but they its obsolete? is it true? personally i do not see much point or advantage over directfb, as most cards do not get acceleration with kdrive and use slow vesa modes anyway. btw. what is your video card? many cards do not get accel or maintained drivers even with standard Xorg... can you test at all how Xorg works on your platform? sticking some larger drive or using root-over-nfs for testing shouldn't be so difficult... this would allow you to just first-hand experience test various distros and options... also you did not mention which CPU TYPE your embedded arch uses. is it x86? arm? something else? -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: ssh tunneling for a newbie :)
Hello ! I am currently working on some bioinformatics project. I installed a software called ProgressiveMauve for genome alignment on the company server. In fact, it needs to forward the X11 window to my mac in order to visualize the alignment. Thanks a lot in advance ! Regards, Mathieu Here is whet I get back when I call the software, I connected with ssh -X * IP* *math...@xmicr2:~/Bioinformatics/mauve_2.3.1$ ./Mauve **connect 132.208.67.10 port 6000: Operation timed out Exception in thread main java.lang.InternalError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable. try 1)ssh -Y instead of -X 2)make sure server is allowing to forward X connections (sshd_config) it is often disabled by paranoid sysadmins... ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: ssh tunneling for a newbie :)
try 1)ssh -Y instead of -X 2)make sure server is allowing to forward X connections (sshd_config) it is often disabled by paranoid sysadmins... 3: Allow the connection on the client side. Easiest way is xhost + which allows any server to display on your client. Optionally you can restrict what servers are allowed (see man xhost). this should not be nessesary when using ssh , and allowing just anyone displaying stuff on your screen on client requires cautious firewalling - mind you this allows just like anyone catching keyboard and mouse events. (i.e. via using x2x ). usually connections should originate from localhost , and as long as console from which ssh has properly configured variables, and i.e. starting xterm from it (or any other x app) actually works, ssh tunnel should work too. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X lib support for embedded systems.
Hello there. I am developing graphics system to one of our touch screen keypad. I planned to use fltk-2.0 to achieve the same. For this I required X11. But as the X11 is very huge, I wanted a slimmed down version of the same. Basically X11 and fltk must occupy not more than 20MB! Fltk basically uses these libraries from X11: -lXext, -lXft, -lXcursor, -lXinerma and -lXi. Can anyone help me in building X11 for my system? X windows is not appropriate for embedded platforms , try using directfb port of fltk (if it's still working...) or take peek at Xfast and clones... -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X lib support for embedded systems.
On Wed, 11 Aug 2010, Mart Raudsepp wrote: On T, 2010-08-10 at 16:15 +0200, Piotr Gluszenia Slawinski wrote: Hello there. I am developing graphics system to one of our touch screen keypad. I planned to use fltk-2.0 to achieve the same. For this I required X11. But as the X11 is very huge, I wanted a slimmed down version of the same. Basically X11 and fltk must occupy not more than 20MB! Fltk basically uses these libraries from X11: -lXext, -lXft, -lXcursor, -lXinerma and -lXi. Can anyone help me in building X11 for my system? X windows is not appropriate for embedded platforms , I disagree with that sentiment. X.org works fine on embedded platforms, and is used on such systems with success. In fact I have built a system on top of a touch screen with Xorg, including a full XUL based browser. My storage space limitation was 64MB, so I stopped optimizing for that after I got to a 43MB squashfs system. i should have been add 'currently'. i also recall long gone times when i could build 3.3.6 XFree which would run on 486 with 8M of ram , and squash the (static!) binary to just 2M. perhaps with uclibc this could be even smaller. main problem those times are long gone :/ numbers like 20M start to appear, and Xorg is not really optimised for embedded devices performance-wise. http://83.18.229.190/minimalistix_linux/static-binaries/XF86_SVGA this one is static binary which is pretty old and has ~4M footprint, and since then i could not build either anything smaller, or anything which would perform better, even though i've tried many times. actually uclibc Xorg binary i use atm (so dynamic linked) totals to 1.4M... and obviously one needs to include also drivers, xorg components, etc... even though one could probably reach the '20M' limit, it consumes vast amounts of memory when running, and is painfully slow. definitelly not way to go when one needs to perform just simple task on embedded device... except 'embedded' is just it's marketing buzzword. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 1 Jul 2010, Fernando Carrijo wrote: Tiago Vignatti tiago.vigna...@nokia.com wrote: If I have more motivation I'll try to get some stats comparing different versions of the server development and maybe other modules. Also, if you are interested on different kind of statistics I can run more. Suggestions are very welcome and appreciated (for instance fixing contributor - company)! A year or so ago, someone pointed me out a PhD dissertation in which a For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. most of changes being done are fixes, and do not contribute to structural changes in Xorg. i would be more interested in overall history graphs (since 3.3.6 release), with semantic analysis, MPX changes, etc. also note 'big players' usually implement same changes 'small players' do - which make software functional for their particular purpose, not nessesairly making development any easier for other cases. main difference is changes confidence factor. i've been silently following X development since at least 10 years, incl. vnc branches and i would surely hold out enthusiasm due to recent changes being made and planning outcomes from such short period of time recent stats did present. otoh i am very glad so many people still do contribute and maintain knowledge about code structure - imho this wishes the project at least next several years of existence. greetings and thanx to all for their great work through all those years. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, 1 Jul 2010, Jonathan Corbet wrote: On Thu, 01 Jul 2010 16:15:58 -0300 Fernando Carrijo fcarr...@yahoo.com.br wrote: For sure the information contained in git logs don't measure how high-level the changes are being submitted, but it would be nice to devise some metrics, apart from the usual LOC, which could help us visualize the architectural impact caused by the big players. I've wanted such a metric for a long time. Lines of code is a terrible metric for work done in general, even if you don't want to make a distinction between architectural and other changes. Changeset counts aren't really any better. Among other things, both create poor incentives if people actually start to care about the numbers. That said, I've still not found a better way of trying to measure who's doing the work, especially in the context of a high-bandwidth project like the kernel. If anybody has any ideas, I'm all ears... i doubt there is without engaging extra analytic workforce. i think while project will 'run' on it's own for several years, if anyone cares, separate semantic description and comment framework could be performed - altrough i doubt it can be done with such scarce resources like now - perhaps some university could be interested , but i again doubt it will be able to analyse such large project 'in spare time'. i certainly feel larger analytic brainstorm will be needed in course of next few years, and modularising X and code cleanup was major step forward it happening. though otoh when you look at 'bare numbers' of amount people interested in development there is serious doubt if project will be ever rebuilt , branched or sustained... there is still hope though at least major shortcomings will be spotted, and it will keep functionality and stability for next decade, even with even more shrinking interest and resources . greetings. -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: stateless thin cliens with decent graphics performance - possible?
This is all good and well, but thanks to VNC, the graphics performance is horrible, especially on the bigger screens. (For example, on my 1600x1200 monitor, I can clearly follow the full-screen windows refreshing, which is no big feat, since it takes several seconds.) i use vnc myself, and usually network is the bottleneck. did you checked what is bottleneck in your case? if you are using decent thin clients, you could consider using i.e. tigervnc or other vnc server providing more robust, but lossy compression (using it myself, and it works pretty nice). playing with i.e. deferupdate option on server and compresslevel on client is also worth trying. main difference from x session seems to be fact that while x session can i.e. clear screen with single command sent over network, it means sending whole screen data with vnc. similiar issue occurs with remote X session. even though your app might be full-screen, it could modify on-screen contents using much smaller commands sent via tcp/ip, which may bring larger effect (i.e. text scrolling up/down), while vnc has to send whole data instead. quite good 'benchmark' of vnc vs plain X seems to be 'xaos', as it just sends whole 'result' of it's calculations to client as plain image buffer. set it to'continous rotation' (press 'o' and select it). once started, check cpu usages, and network usages, irq load, etc. try to compare performance via vnc with various levels of compression and deferupdate setting, with 'bare' X session . try various sizes, and see how quickly performance drops once network saturates :) i've once had idea of using 'lossy' screen update algorithm, sending just random Nth line, instead of line-after-line method, assuming next update will occur soon anyway and 'gaps' will be filled. ofcourse vnc client had to also issue 'full' update if last incomplete update of region was not followed by any subsequent update. such method is succesfully used by many 8-bit demoscene coders to off-load cpu with i.e. vector graphics effects, as mere copy-to-screen consumes lot of cpu time, while it seems 'interactivity' has more priority over loss of some visual information (i.e. it gives more 'eye comfort' when object is displayed with 50fps with some data missing, than if it's displayed with all detail but @ i.e. 10fps) unfortunatelly to date noone had implemented such method to vnc clients and servers, and personally i'm too lame to code that :) greetings -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
fpit dropped from recent releases
Hello. I am user of said driver (fpit) , and it worked fine on quite all releases since recent ones, where it's support seem to be dropped. http://bugs.gentoo.org/show_bug.cgi?id=321175 here there seem to be another unhappy user and also patch provided :) is it some big deal to include it in xorg-drivers now? -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: fpit dropped from recent releases
-- On Wed, 2 Jun 2010, Alan Coopersmith wrote: Piotr Gluszenia Slawinski wrote: Hello. I am user of said driver (fpit) , and it worked fine on quite all releases since recent ones, where it's support seem to be dropped. http://bugs.gentoo.org/show_bug.cgi?id=321175 here there seem to be another unhappy user and also patch provided :) is it some big deal to include it in xorg-drivers now? Ask gentoo, as they'd be the ones who removed it from their distro - the patch provided in that bug report came from X.Org upstream: http://cgit.freedesktop.org/xorg/driver/xf86-input-fpit/commit/?id=7d203627e7e3e7a6f8d0e847ed650b0b89760c09 It does look like no one has pushed out a tarball release since Peter made that fix - it certainly could use someone stepping up as maintainer if they actually cared about it and had access to the hardware. hmm, sorry if i ask about something obvious, but i am still bit confused, if xorg-drivers-1.7 and up seem to contain fpit (but it is marked as masked in use flags), shouldn't the patch just be moved along to this package, instead of keeping separate fpit driver ? simplest fix for users before anyone 'responsible' will react sounds like just creating custom ebuild which patches 'old' driver, or new xorg-drivers package to make fpit compile, question is which thing should be patched? (excuse me, i'm just user...) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Smooth scrolling
On Fri, 2 Apr 2010, Dima Ryazanov wrote: I would love this feature. I'm running Linux on a MacBook, and smooth scrolling is the one feature I miss from OS X. sorry for 'hijacking' the thread, but on the occasion it reminded me one feature i quite miss in Xorg for bit weaker machines (or insane resolutions, in which even pretty decent ones seem 'slow' ) idea would be to defer scrolling updates, so i.e. just tiled pattern would be scrolled up, each 2nd line , etc. (there would have be many of such 'cpu saving' patterns as various hardware benefits from various methods, and also various users have various preference depending also on various application, i.e. for text scrolling each 2nd. line would degrade quality of text rendering it unreadable and making scrolling tiresome,but i.e. large solid tiles or blocks would allow to quickly scroll i.e. to next paragraph without loosing focus on the text). point of this to allow quick (and sometimes also visually smooth) scrolling not taking much of cpu and not blocking pci/agp/whatever bus significantly. ofcourse once user stops scrolling (or reaches slow enough scrolling rate), contents of scrolled element/window should be updated usual-way. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Tue, Mar 30, 2010 at 5:31 AM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... libc5 wasn't even glibc. It was the Linux libc. Read the glibc wikipedia article. this limits nvidia driver usage to specific libc implementation, with specific version. glibc is kind of the de facto libc. What do you expect here? Them not to link to the C library? Provide a second binary linking against uclibc? And what then about all the other libc's? preferably providing code plainly compiling using system libc. most of restricted code is in kernel itself, and code using libc can be licensed with their own license. also they could make version not running 3d, which will plainly not crash if lackin libGL - but continue running in 2d instead. (so without the dependency) ad. using generic nv driver instead of binary (many people would still prefeer that) - why not also documenting it more to allow other people maintain it ? if the intention is to maintain sales of GPU's ofcourse , or whatever motivates nvidia team to continue support... ad alternatives - nothing stops them from releasing their own OS either, allowing running guest OS within VM and contacting X windows using tcp/ip, or implementing own X solely in hardware and leaving only code for socket or tcp/ip communication via pci bus... --___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Mon, 29 Mar 2010, Andy Ritger wrote: On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote: -- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) Hello, Piotr. No, glibc is not statically linked into NVIDIA's libGL.so, if that is what you mean to imply. no, it just expects glibc being in the system. If uclibc provided the same ABI as glibc then I would expect NVIDIA's libGL.so to work with uclibc. However, my understanding is that binary compatiblity (either with glibc or even with prior uclibc releases) is a non-goal of the uclibc project. yes, it is not binary-compatible glibc. For better or worse, the NVIDIA driver is provided as binary-only, so it is not terribly well suited to deal with system library binary interface changes. Sorry, - Andy well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... this limits nvidia driver usage to specific libc implementation, with specific version. nv driver itself served well for i.e. people who could sacrifice 3d performance in i.e. netbooks, where they would rather focus on battery and storage usage when choosing libc implementation. if it quits being maintained and users are advised to move to binary driver - it would be nice to make it actually compile on such systems... p.s. why nvidia does not set up some price levels on opening parts of drivers like i.e. blender coders did? -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Wed, 31 Mar 2010, Dave Airlie wrote: On Tue, Mar 30, 2010 at 7:31 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: On Mon, 29 Mar 2010, Andy Ritger wrote: On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote: -- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) Hello, Piotr. No, glibc is not statically linked into NVIDIA's libGL.so, if that is what you mean to imply. no, it just expects glibc being in the system. If uclibc provided the same ABI as glibc then I would expect NVIDIA's libGL.so to work with uclibc. However, my understanding is that binary compatiblity (either with glibc or even with prior uclibc releases) is a non-goal of the uclibc project. yes, it is not binary-compatible glibc. For better or worse, the NVIDIA driver is provided as binary-only, so it is not terribly well suited to deal with system library binary interface changes. Sorry, - Andy well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... this limits nvidia driver usage to specific libc implementation, with specific version. nv driver itself served well for i.e. people who could sacrifice 3d performance in i.e. netbooks, where they would rather focus on battery and storage usage when choosing libc implementation. if it quits being maintained and users are advised to move to binary driver - it would be nice to make it actually compile on such systems... Just to posit, if you are intending on installing the nvidia binary driver on a niche built by hand system, then I don't think the glibc overheads would give you much cause. Wierdly you'd have gotten better battery life most likely using the binary driver since -nv doesn't have any powersaving abilities. So you are probably shooting yourself in the face to spite your foot or something. yes, current state of nvidia driver(s) make such choice bad. glibc overhead is not something 'worth' the 'powersaving abilities' in many cases, so best choice is usually to just get laptop with other GPU chipset, and use whatever one feels works best to him, despite being 'niche' . i'm not going to discuss performance issues of such setup on this group as this is largedly offtopic, recalling also times of libc5 transition, when there was large group of people not believing 'heavy' glibc implementation will be ever used by larger group of users... also linux is 'niche' system in general , so this makes little point. my point of above is that encouraging users to use driver which does not compile on plenty of systems, and is limited in future development by simple design flaw , will generate lot of un-satisfied users. it is not impossible thing to fix it, while there is still anyone caring to maintain the driver (note many cards will be 'obsoleted' by nvidia pretty soon and people will be left on their own with the drivers... better them be as flexible and adaptable for system upgrades as possible) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
-- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
new kadu+nvidia=crash
tested on 'old' 1.6.5 Xorg and also 1.7.8. upgrading 'kadu' IM to the current stable in gentoo (along with qt-core, etc) , opening window and trying to type something crashes whole X as follows : http://83.18.229.190/Xorg/Xorg.nvidia.kadu.log note acceleration is disabled as i've not compiled everything after upgrade , but on 'old' X it was crashing aswell with everything loaded (it should not anyway...) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GSoC: KMSifying cirrus?
Cirrus cards are kind of obsolete, but I suppose *would* be nice to have one more KMS driver, perhaps a relatively simple one that could be an easy-to-follow model for other KMSification efforts. they appear very commonly as 1)integrated in laptops 2)integrated in 'server' motherboards lot of such hardware finds it's second home , and personally i run old dual cpu, 512M 'server' which i've got for price of just shippng, with exactly such 'card' integrated . i also own few 'old' laptops (486) with one. mind you 486 laptop can consume as low as 1W of power, and one can usually get dozen of them in price of one 'modern' which can hardly get below 5W... ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
xorg-server profiling
I was wondering if someone did/does xorg profiling. any special precautions for someone who might want to try? -- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: to neomagic users and devels
i've had a peek into source, and it seems that there is problem with ImageWrite and colour expansion... runnin x11perf is quite interesting, it seems this chipset is not so dead slow, and many modes are quite quick... except the ones which are not ;) ad. older X - as there is no accel of i.e. ImageWrite , it is done by software, and i think such 'software' functions got somehow broken recently. afterall painting just 16x16 pix cursor in gimp should not be so slow, even without acceleration at all on pentium... such things could be performed on zx-spectrum lightning fast... -- On Thu, 4 Mar 2010, Risto Suominen wrote: I've installed Debian Lenny on a Fujitsu B110 mini notebook, probably quite similar to yours internally, and it is quite slow, indeed. I also have Neomagic on a Dell Latitude CPi 300 MHz P2 with VectorLinux 5.0. I don't remember any unusual slowness with that one. Older X? Just a thought... Risto ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
to neomagic users and devels
hello. I am (un)fortunate owner of old tablet pc (fujitsu stylistic 2300) equipped with neomagic chipset. I would like to thank developers of current driver - it works, it is stable, it has gentoo ebuild. It allows me to use this pretty old machine for (let's say portable) gps and sketchpad. now the cons. the video driver is painfully slow... even in 16bit depth. i am using tangogps, as it seems to be most lightweight map display software, working very smooth even on old computers, but on neomagic moving map around is so slow one can see map being copied to the tiles... i also TRIED to use gimp, but response is so slow it is impossible to draw even using very simple tools (like 1x1 pix pencil) i've resorted to mtpaint as this seems to be bit faster... but... even on much slower machine (p133) with less cache (256 L2) and s3 or matrox video chipset, using both tangogps and gimp is possible and quite smooth. also , trying to use (quite robust, running without problems on p100 machines) 'fuse' emulator (zx-spectrum) is impossible - screen refresh is way too slow , and blocking everything (it is only 192x256 window!) , no matter if using x11 or sdl driver... what might be cause of such slow operation of neomagic driver? i've tried reducing bit depth to 15 and 16bpp, and (i think) setting on/off all available options, including disabling 'strangelockups' one... machine itself is not so slow, it has 512k L2 cache ,96M of 100mhz so-dimm memory (so with quite decent timing) , and 233mhz cpu. it can play small movies downloaded from youtube using mplayer, and is even able to render pages in google chrome. greetings -- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
