To ease this process, I wrote a small script that does almost the same described in Lizardo’s post, with some new pseudo features. It needs some improvements, the known ones are marked with #XXX – contributions are welcome!

It consists in 2 files, the script and a config file where the user can customize the directories where things will be installed, the directory of the downloaded files, the version of S60 that will be used. Initially it’s ready for S60 3rd edition FP2 and S60 5th edition (Check here the version of your target device), etc.

Running the script, the first step shows the URLs to files you have to download, but need login or other kind of interaction with the website. The script is a nice guy, when it’s possible “he” asks if you allow him to open those URLs in your default browser =)

The script then downloads other files that are direct accessible and the installation begins. If everything goes right, in the end your environment will be ready for Qt-S60 development.

Wanna try? Download a it here or git clone it:

git clone git://littlechina.org/anselmo/setupQtS60env

That’s it =)

ToDo:

• Simplify updates of Qt-S60 in a environment already in use.
• Solve the #XXX in the script
• Probably there are other things that I don’t remember now =)
• UPDATE: 2009-10-17: There are some issues in qmake when using DEPLOYMENT
• UPDATE2: 2009-10-19: The old daily builds aren’t available anymore, a message there says that they “back tonight hopefully”
• UPDATE3: 2009-10-20: Builds are back =)
• UPDATE4: 2009-11-01: The gnupoc patch for Qt-S60 needs to be uptaded =/ .
• Hopefully it’s going to save us =) http://labs.trolltech.com/blogs/2009/10/28/a-new-symbian-toolchain-for-linux/

Adquiri recentemente um case para HD externo CoolerMaster X-Craft 310 e acabei sendo pego de surpresa quando vi que ele não era devidamente reconhecido. Nos logs apareciam mensagens do tipo:

usb 7-3: new high speed USB device using ehci_hcd and address 13
usb 7-3: device descriptor read/64, error -32
usb 7-3: device descriptor read/64, error -32
usb 7-3: new high speed USB device using ehci_hcd and address 14
usb 7-3: device descriptor read/64, error -32
usb 7-3: device descriptor read/64, error -32
usb 7-3: new high speed USB device using ehci_hcd and address 15
usb 7-3: device not accepting address 15, error -110
usb 7-3: new high speed USB device using ehci_hcd and address 16
usb 7-3: device not accepting address 16, error -110
hub 7-0:1.0: unable to enumerate USB device on port 3
usb 5-1: new full speed USB device using uhci_hcd and address 20
usb 5-1: device descriptor read/64, error -32

Bateu a dúvida se o problema era com o hardware, mas isso foi descartado ao verificar que o o case+HD funcionaram no Windão. Procurando na Internet, acabei encontrando várias queixas no fórum da CoolerMaster sobre problemas com vários outros modelos. Todos eles receberam respostas (sobre o suporte a Linux) do tipo: “Unfortunately it isn’t. We apologize for any inconvenience.”

Resolvi então dar uma olhada no bugzilla do kernel, onde encontrei o bug report 8639 que fala sobre o modelo X-Craft 360 e de uma solução para o mesmo problema que eu estava tendo.

Há um e-mail enviado por Jaroslav Kysela para a lista linux-usb que explica com mais detalhes o problema e a solução. O problema parece residir no fato de que em geral os chips USB 2.0 levam cerca de 5 segundos para responderem à requisição USB_REQ_GET_DESCRIPTOR, entretanto o chip utilizado na linha X-Craft demora cerca de 10 segundos. Assim, com o timeout, não há a correta identificação do dispositivo.

Até o kernel 2.6.27-rc8 a alteração não havia sido incorporada ao código, mas provavelmente algo será feito nesse sentido numa versão futura. Até lá, o patch sugerido dá conta do serviço. O que é feito nele é a simples alteração do timeout de 5 para 12 segundos.

Testei com a versão 2.6.27-rc8, mas a alteração deve funcionar também com a 2.6.26.

—

PS1: O patch aqui disponibilizado não é meu (infelizmente =P), mas sim a versão que usei da segunda solução proposta pelo J. Kysela.

PS2: o usuário “tinga” usado no fórum da CoolerMaster é uma homenagem à uma grande personalidade da Unicamp =)

PS3: Correções sobre eventuais bobagens que eu tenha escrito aqui são bem vindas.

EDIT PS4: Pessoas, não adianta só aplicar o patch e esperar algo acontecer, precisa recompilar o kernel, instalar e rebootar né…Adquiri recentemente um case para HD externo CoolerMaster X-Craft 310 e acabei sendo pego de surpresa quando vi que ele não era devidamente reconhecido. Nos logs apareciam mensagens do tipo:

usb 7-3: new high speed USB device using ehci_hcd and address 13
usb 7-3: device descriptor read/64, error -32
usb 7-3: device descriptor read/64, error -32
usb 7-3: new high speed USB device using ehci_hcd and address 14
usb 7-3: device descriptor read/64, error -32
usb 7-3: device descriptor read/64, error -32
usb 7-3: new high speed USB device using ehci_hcd and address 15
usb 7-3: device not accepting address 15, error -110
usb 7-3: new high speed USB device using ehci_hcd and address 16
usb 7-3: device not accepting address 16, error -110
hub 7-0:1.0: unable to enumerate USB device on port 3
usb 5-1: new full speed USB device using uhci_hcd and address 20
usb 5-1: device descriptor read/64, error -32

Bateu a dúvida se o problema era com o hardware, mas isso foi descartado ao verificar que o o case+HD funcionaram no Windão. Procurando na Internet, acabei encontrando várias queixas no fórum da CoolerMaster sobre problemas com vários outros modelos. Todos eles receberam respostas (sobre o suporte a Linux) do tipo: “Unfortunately it isn’t. We apologize for any inconvenience.”

Resolvi então dar uma olhada no bugzilla do kernel, onde encontrei o bug report 8639 que fala sobre o modelo X-Craft 360 e de uma solução para o mesmo problema que eu estava tendo.

Há um e-mail enviado por Jaroslav Kysela para a lista linux-usb que explica com mais detalhes o problema e a solução. O problema parece residir no fato de que em geral os chips USB 2.0 levam cerca de 5 segundos para responderem à requisição USB_REQ_GET_DESCRIPTOR, entretanto o chip utilizado na linha X-Craft demora cerca de 10 segundos. Assim, com o timeout, não há a correta identificação do dispositivo.

Até o kernel 2.6.27-rc8 a alteração não havia sido incorporada ao código, mas provavelmente algo será feito nesse sentido numa versão futura. Até lá, o patch sugerido dá conta do serviço. O que é feito nele é a simples alteração do timeout de 5 para 12 segundos.

Testei com a versão 2.6.27-rc8, mas a alteração deve funcionar também com a 2.6.26.

—

PS1: O patch aqui disponibilizado não é meu (infelizmente =P), mas sim a versão que usei da segunda solução proposta pelo J. Kysela.

PS2: o usuário “tinga” usado no fórum da CoolerMaster é uma homenagem à uma grande personalidade da Unicamp =)

PS3: Correções sobre eventuais bobagens que eu tenha escrito aqui são bem vindas.

EDIT PS4: Pessoas, não adianta só aplicar o patch e esperar algo acontecer, precisa recompilar o kernel, instalar e rebootar né…

anselmo@persephone:~$ mkfs.ext2 /dev/sda
mke2fs 1.40.8 (13-Mar-2008)
/dev/sda is entire device, not just one partition!

Proceed anyway? (y,n)

por sorte não o fiz como root heheh… Tá, podem me chamar de nilba agora.

PS: pra galera Windera, quase fiz um “format c:”

PS2: Embora alguns acreditem que “Living on the Edge” é do Bon Jovi, obviamente é do Aerosmith =P

O script encodepsp pode ser encontrado aqui.

Uso: encodepsp inputfile outputfile

ou: encodepsp dvd://1 movie.mp4

Andei conversando a respeito, percebi que é possível melhorar alguns parâmetros. Como eu nunca mexi muito com isso, preciso dar uma estudada hehe. Quem sabe em breve consigo algo melhor =) .